[clc-devel] PortDB - testing stage opened
![](https://secure.gravatar.com/avatar/8db383c2bfadbeaf60811f65ebb4642d.jpg?s=120&d=mm&r=g)
Hi, most of you might have noticed that I made a frontend to the mysql-based portsdatabase on crux.nu availible in the wiki: http://crux.nu/cgi-bin/trac.cgi/wiki/PortDB So please try it out and give some feedback on usability, improvement-suggestions, missing features and so on. Next week I will contact all httpup repo maintainers to check which repos are still active, suggest them to join the new contrib and fill up the db step by step. There are two things left I'd like to discuss: 1.) How should the application procedure for the portdb look like? The simple solution is we allow only repos which take part in the new contrib. So the quality of ports and active maintenance guaranteed. The other way is that every repo can be listed in the db. In this case should there be a registration form (like it is now with the old db) or is it better to use the mailing list (like we do for everything)? 2.) The other question is how to handle .sync-tagged (i.e. contrib-) ports in the origin repository? The old db lists the port both in contrib and in the httpup repo (which falsifies the duplicate stats btw.). I think it is better to exclude contrib ports from the origin httpup repo in the db listing. What do you think? Regards Till -- http://www.tbmnet.de ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
![](https://secure.gravatar.com/avatar/98dc28bf87ce4e0590da1628e6fa8fd2.jpg?s=120&d=mm&r=g)
--- Till Biedermann wrote:
Hi,
most of you might have noticed that I made a frontend to the mysql-based portsdatabase on crux.nu availible in the wiki:
Lookin good :) I take it you plan to implement viewing the port (Pkgfile, .footprint, etc..) soon?
1.) How should the application procedure for the portdb look like?
The simple solution is we allow only repos which take part in the new contrib. So the quality of ports and active maintenance guaranteed.
The other way is that every repo can be listed in the db. In this case should there be a registration form (like it is now with the old db) or is it better to use the mailing list (like we do for everything)?
I don't have strong feelings either way. I think, perhaps, that showing ports from all repositories might be nice.
2.) The other question is how to handle .sync-tagged (i.e. contrib-) ports in the origin repository? The old db lists the port both in contrib and in the httpup repo (which falsifies the duplicate stats btw.). I think it is better to exclude contrib ports from the origin httpup repo in the db listing. What do you think?
Yea, I like that - each port only shows up once. *Or* you could show them in the original httpup, too, perhaps with some visual cue, indicating that it's also available in contrib. :) Nice job, thanks for working on this. Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
![](https://secure.gravatar.com/avatar/8db383c2bfadbeaf60811f65ebb4642d.jpg?s=120&d=mm&r=g)
Jay Dolan wrote:
Lookin good :) I take it you plan to implement viewing the port (Pkgfile, .footprint, etc..) soon?
I construe this as a feature request. So here it is: http://crux.nu/cgi-bin/trac.cgi/wiki/PortDBportinfo?repository=core&port=firefox Displaying .footprint and .md5sum inline is not so important imho. I think the anchors for these files are enough. Other opinions?
... I think it is better to exclude contrib ports from the origin httpup repo in the db listing. What do you think?
Yea, I like that - each port only shows up once. *Or* you could show them in the original httpup, too, perhaps with some visual cue, indicating that it's also available in contrib. :)
I have chosen the way of complete exclusion. But the count of contributed ports is listed in the overview for each repository: http://crux.nu/cgi-bin/trac.cgi/wiki/PortDBrepoinfo?repository=jaeger Tilman Sauerbeck wrote:
The heading used in the "Duplicates" view is the same as the one used in the "Search" view. Slightly irritating.
The dupe-detection thing is a nice feature :)
Looks like you reviewed the old db :-) But anyhow the dupe-detection _is_ a nice feature. So here it is: http://crux.nu/cgi-bin/trac.cgi/wiki/PortDBstats#Duplicates
Did you consider removing ports that are in contrib and *one* other user repository only? In that case, the database could check whether it's that user repo the port is synced to contrib from, and not report a dupe in that case.
Like mentioned above, I exclude all (.sync)tagged ports from normal httpup repositories. This is a clean and easy to implement way of solving this problem. Last but not least some (final) words to the application procedure. I suggest the following: Participation in the contrib is _not_ required, so every repo can be listed in the PortsDB. When a maintainer wants to have his repo listed, he has to announce it on the official mailing list and ask for inclusion in the db. So everybody can have a look at the new repo and if something is not ok, it can be discussed there. When there are no objections arising after a period of 3-5 days the repo will be added to the db. Any comments on that? (silence will be assumed as agreement :-)) Regards Till -- http://www.tbmnet.de ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
![](https://secure.gravatar.com/avatar/bd0689ae9ceb20348c3b826b3dd612d4.jpg?s=120&d=mm&r=g)
Till Biedermann [2006-01-15 19:49]:
most of you might have noticed that I made a frontend to the mysql-based portsdatabase on crux.nu availible in the wiki:
Yes, I have been using the new for quite some time :D Didn't notice it wasn't finished :o
So please try it out and give some feedback on usability, improvement-suggestions, missing features and so on.
The heading used in the "Duplicates" view is the same as the one used in the "Search" view. Slightly irritating. The dupe-detection thing is a nice feature :) Did you consider removing ports that are in contrib and *one* other user repository only? In that case, the database could check whether it's that user repo the port is synced to contrib from, and not report a dupe in that case. Regarding the register procedure: s/CLC member/CRUX developer/g :)
1.) How should the application procedure for the portdb look like?
The simple solution is we allow only repos which take part in the new contrib. So the quality of ports and active maintenance guaranteed.
The other way is that every repo can be listed in the db. In this case should there be a registration form (like it is now with the old db) or is it better to use the mailing list (like we do for everything)?
Users might not want to .sync all of their ports they publish via httpup (like me :P). So I'd say keep it the way it is + enhancements for contrib.
2.) The other question is how to handle .sync-tagged (i.e. contrib-) ports in the origin repository? The old db lists the port both in contrib and in the httpup repo (which falsifies the duplicate stats btw.). I think it is better to exclude contrib ports from the origin httpup repo in the db listing. What do you think?
I agree. See also above for some more comments on that. Nice work :) Regards, Tilman -- GnuPG key available at http://code-monkey.de/files/tsauerbeck-public-key.asc
participants (3)
-
Jay Dolan
-
Till Biedermann
-
Tilman Sauerbeck