[clc-devel] Ports reorganisation?
Hi everybody, since it's been quiet for a while, I'll do my best to annoy you all as usual. Some consideration about the current CLC port tree and related topics: [*** unmaintained ***] Some time ago we discussed about a possible removal of the /unmaintained collection; I suggest to open up the previous to casual contributors and not-so-tested ports, in an effort to unify the many spotted httpup collections. The 'new' unmaintained collection would of course be totally unsupported, and be separate from /contrib. This could be done in other ways than cvs, if needed.(httpup hack?) [*** mea culpa ***] I'm ditching my httpup repository. I'll try to: - transfer the useful ports into /contrib - remove duplicate ports - trash the one I rarely use (Who cares, you'll say) As a CLC maintainer I found that having a separate repository often ends up with duplicated ports, de-centralization, etc. Additionally It's quite common for me (as for many others I suppose) to create custom ports from scratch or with slight modifications or updates of existing ports, thus adding other mess to the ports available on my system. I'm going to stop this trend, removing the unneeded ports and try to collaborate a little more with other maintainers, eventually explaining why I feel my port is an improvement. Btw, this could be easier with a more open /unmaintained collection. [*** opinions? ***] I think a global step towards stricter collaboration and centralization of ports* could improve the CRUX user experience and save precious manpower (packagerpower?). In my opinion this point is particularly important, since the CRUX community cannot count on thoushands of contributors. What do you think? Best regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com * Of course private httpup repos of most exotic / highly customized stuff will continue to exist.
Hi Simone, On Mon, 05 Jan 2004 01:11:37 +0100 Simone Rota <sip@varlock.com> wrote:
[*** unmaintained ***] Some time ago we discussed about a possible removal of the /unmaintained collection; I suggest to open up the previous to casual contributors and not-so-tested ports, in an effort to unify the many spotted httpup collections.
I personally vote for removing 'unmaintained' completely. I'm a big fan of httpup repositories, because they're giving a wide range of people the chance to distribute their ports. Not every user has (shell-) access to a server for running cvsupd. Webspace is cheap & everywhere available.
(Who cares, you'll say) As a CLC maintainer I found that having a separate repository often ends up with duplicated ports, de-centralization, etc.
De-centralization would be okay - but we need a central index of all ports. -- Daniel Mueller Berlin, Germany (OpenPGP: 1024D/126EC290)
On Mon, 2004-01-05 at 22:37, Daniel Mueller wrote:
Hi Simone, Hi Daniel,
I personally vote for removing 'unmaintained' completely. I'm a big fan of httpup repositories, because they're giving a wide range of people the chance to distribute their ports. Not every user has (shell-) access to a server for running cvsupd. Webspace is cheap & everywhere available.
De-centralization would be okay - but we need a central index of all ports.
I guess for some aspect is a matter of personal taste. The idea of a central index of httpup repos is good, in fact I've been using a port containing httpup files for a while (actually some consideration in my previous mail comes from experiences using that port). My point is that a central repository of 3rd party (or unmaintained if you prefer) would: - limit duplicates - improve the quality of ports: in theory ports from the common repository are more exposed to the users, thus possible problems are easier to discover. I won't mind if the various httpup repos are physically on a central server or not (CLC providing a central index as you suggest), so I think we share some point. Of course we should consider security implications, but that's another story. -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Hi everybody, since it's been quiet for a while, I'll do my best to annoy you all as usual.
Some consideration about the current CLC port tree and related topics:
[*** unmaintained ***] Some time ago we discussed about a possible removal of the /unmaintained collection; I suggest to open up the previous to casual contributors and not-so-tested ports, in an effort to unify the many spotted httpup collections. The 'new' unmaintained collection would of course be totally unsupported, and be separate from /contrib. I've discussed with Jürgen and Martin regarding unmaintained, and I now
[*** mea culpa ***] I'm ditching my httpup repository. I'll try to: - transfer the useful ports into /contrib - remove duplicate ports - trash the one I rarely use
(Who cares, you'll say) As a CLC maintainer I found that having a separate repository often ends up with duplicated ports, de-centralization, etc.
Additionally It's quite common for me (as for many others I suppose) to create custom ports from scratch or with slight modifications or updates of existing ports, thus adding other mess to the ports available on my system. I'm going to stop this trend, removing the unneeded ports and try to collaborate a little more with other maintainers, eventually explaining why I feel my port is an improvement. Btw, this could be easier with a more open /unmaintained collection. I agree with most parts of what you say. When looking at the current httpup repositories, I think the amount of duplication is not that bad
Hello, First of all best wishes for 2004. It's probably a good time to think and discuss a bit about CLC, but first of all I'd like to thank everyone involved in CLC including the new maintainers: The web database (which is always a few ports off though ;-)) says we have 464 ports in contrib, 310 in unmaintained. Now I personally think this is great compared to the situation we had earlier. On Mon, Jan 05, 2004 at 01:11:37 +0100, Simone Rota wrote: think that we should keep it and define a procedure to allow submission of changes back to it. This is because of the higher level of trust because someone from CLC at least _looked_ at it ("many eyes" as Martin called this). IMHO this is a very good argument. The important thing here is to make sure that applying submitted changes is really simple and that a lot of checks are done by scripts (e.g. footprints). And finally I'd keep the policy that ports from unmaintained should automatically lose their UNMAINTAINED tag when not touched for $SOME_TIME. Like this, only actively used ports remain in our collections. Of course, there should be a warning mail to a mailing list ("port XY is about to be removed from unmaintained"). though. IMO there is room for both CLC and private httpup repositories, just because I think there are ports which are too specific or functional duplicates (which doesn't make them exotic yet). I just think we should first of all open unmaintained for contributions so people don't duplicate newer versions of these ports in their httpup repos. Then we should try to propagate httpup repositories with a certain standard (e.g. no dups). I could even imagine to have to kind of "clc-contrib" subproject, which fetches the httpup repositories from the respective httpup maintainers and serves it as a single httpup repo. This would also be the place to recruit new maintainers. Of course, this is probably quite some work, and we lose the "many eyes" advantage.
[*** opinions? ***] I think a global step towards stricter collaboration and centralization of ports* could improve the CRUX user experience and save precious manpower (packagerpower?). In my opinion this point is particularly important, since the CRUX community cannot count on thoushands of contributors. What do you think? I think it's central port availability is quite important; to me the "many eyes" argument counts even more though.
Looking forward to some more comments, Best regards Johannes -- Johannes Winkelmann mailto:jw@tks6.net Biel, Switzerland http://jw.tks6.net
Hello,
I've discussed with Jürgen and Martin regarding unmaintained, and I now think that we should keep it and define a procedure to allow submission of changes back to it. This is because of the higher level of trust because someone from CLC at least _looked_ at it ("many eyes" as Martin called this). IMHO this is a very good argument. The important thing here is to make sure that applying submitted changes is really simple and that a lot of checks are done by scripts (e.g. footprints).
Who should be able to submit changes? If someone can change Pkgfile he should also be able to change footprints. And he could replace a link with a link pointing at a backdoor... Best regards, Tilo
Hi, On Fri, Jan 09, 2004 at 13:29:38 +0100, Tilo Riemer wrote:
Hello,
I've discussed with Jürgen and Martin regarding unmaintained, and I now think that we should keep it and define a procedure to allow submission of changes back to it. This is because of the higher level of trust because someone from CLC at least _looked_ at it ("many eyes" as Martin called this). IMHO this is a very good argument. The important thing here is to make sure that applying submitted changes is really simple and that a lot of checks are done by scripts (e.g. footprints).
Who should be able to submit changes? If someone can change Pkgfile he should also be able to change footprints. And he could replace a link with a link pointing at a backdoor... Yeah, that's very true. It's still a lot better if it's reviewed, right? I consider it an improvement if someone independent had a look at it compared to just using the same port from someone's httpup repo. It's just a higher level of trust, not a perfect secure solution.
Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Biel, Switzerland http://jw.tks6.net
On Fri, 2004-01-09 at 10:40, Johannes Winkelmann wrote:
Hello, Hi,
I've discussed with Jürgen and Martin regarding unmaintained, and I now think that we should keep it and define a procedure to allow submission of changes back to it. This is because of the higher level of trust because someone from CLC at least _looked_ at it ("many eyes" as Martin called this). IMHO this is a very good argument. The important thing here is to make sure that applying submitted changes is really simple and that a lot of checks are done by scripts (e.g. footprints).
I just think we should first of all open unmaintained for contributions so people don't duplicate newer versions of these ports in their httpup repos. Then we should try to propagate httpup repositories with a certain standard (e.g. no dups). I could even imagine to have to kind of "clc-contrib" subproject, which fetches the httpup repositories from the respective httpup maintainers and serves it as a single httpup repo. This would also be the place to recruit new maintainers.
Of course, this is probably quite some work, and we lose the "many eyes" advantage.
Sorry for replying a little late, I was reading some comment about arch linux yesterday (don't remember where, sorry. Maybe osnews.com). I think they've a public Incoming collection or something similar; maintainers periodically check ports submissions and updates in this incoming collection and eventually transfer them to unmaintained. To me it sounds a nice system. The first maintainer that has some spare time could do a quick check on the incoming collection and transfer good ports. A question arise: what to check? Since after all that ports will be transferred to unmaintained (or 3rdparty or some other name), I suggest maintainers should only check for a couple of security aspects: - sources are retrieved from a proper url. - no malicious stuff in Pkgfile "build" function. IMHO If the port doesn't build or there are footprint issues we should leave the users / casual contributors the task to submit a patch to the packager or directly to the incoming dir.
And finally I'd keep the policy that ports from unmaintained should automatically lose their UNMAINTAINED tag when not touched for $SOME_TIME. Like this, only actively used ports remain in our collections. Of course, there should be a warning mail to a mailing list ("port XY is about to be removed from unmaintained").
Good idea, the only suggestion I have is to send a cumulative mail periodically (every x months) instead of each time a port is "expiring": Warning: the following ports will be removed: a,b,c...
Looking forward to some more comments, Best regards Johannes
I hope we can find some good implementation of the ideas coming up from this ML; I also hope to have some more time in a month or so* to give some help if needed. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com * My next exams dates: 26.01 - 28.01 - 30.01 - 02.02 - 04.02 - 05.02 more to come on Feb 07..21. sic.
I'm sorry for the late reply, too. I have the following suggestions: 1. unmaintained: we remove it from cvs and copy the plain files to a http-repository. from then on it is distributed by httpup. Without the pros and cons of cvs. 2. We write a php upload page on crux.fh-regensburg.de, where users can upload new ports (as gzipped tarfiles). The files run through a few sanity checks and go directly to the direcory from point 1. The web gui should have the following features: upload a port with information about the date, all other information can be read out of the Pkgfile headers; remove port. So *everybody* can upload a port to the server and *everybody* can remove every port. Could this work (wiki concept)? 3. If a maintainer wants a port of this "everybody can do everything"-repository in contrib, the he can remove it and put it into contrib. I could write a part of the php code, but I have not much time the next weeks. Comments? Bye Martin
Hi Martin, On Wed, Jan 14, 2004 at 09:08:52 +0100, Martin Opel wrote:
I'm sorry for the late reply, too. I have the following suggestions:
1. unmaintained: we remove it from cvs and copy the plain files to a http-repository. from then on it is distributed by httpup. Without the pros and cons of cvs.
2. We write a php upload page on crux.fh-regensburg.de, where users can upload new ports (as gzipped tarfiles). The files run through a few sanity checks and go directly to the direcory from point 1. How about creating this repository from other httpup repositories? Uploading 10+ ports via web frontend is rather inconvenient IMO. Merging
Yeah, that's fine with me the distributed httpup's automatically would make it much cooler :-) This would usually mean: for a port from unmaintained, copy it to your upload directory; do some updates; upload to server -> synced automatically I'd suggest a discussion on GnuPG signing of REPO files to have some information about the packager (most notable: e-mail address), and introduce an additional md5sum check: right now, files fetched from the web are not checked against the REPO md5sum. I could introduce a --pedantic-md5 flag to httpup. Of course, the problem of duplicates needs some rules. IMO packagers should discuss how to merge their ports (of they're not equal) and discuss their differences to get a common solution. I'm not quite sure though what to do if they fail to find a consensus: 1. Discuss and decide in CLC? + probably best for the integrity - maybe a lot of (uninteresting) work - one packages gets turned down, maybe for very small reasons; doesn't improve his opinion of CLC 2. Have multiple ports (mplayer, mplayer-gui) + all kind of wishes are covered - updates are duplicate work - "packaging competition"; don't think that's a good thing In the end I think it's not a bad approach to have duplicates and discuss them in a dedicated mailing list, as you can learn a lot from other packagers. Of course, the httpup approach has some problem as well; packager can disappear, but they're httpup repos are still online. In such cases, we'd need to stop updating from his repo to allow others to maintain his ports... we could require all maintainer to visit an URL with id every month to make sure they're alive. Comments here? Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On Wed, 2004-01-14 at 10:07, Johannes Winkelmann wrote:
Of course, the problem of duplicates needs some rules. IMO packagers should discuss how to merge their ports (of they're not equal) and discuss their differences to get a common solution. I'm not quite sure though what to do if they fail to find a consensus: ..... In the end I think it's not a bad approach to have duplicates and discuss them in a dedicated mailing list, as you can learn a lot from other packagers.
I agree. I dont think duplicate ports are a problem, as long as they use different configure-options (for example --enable_kde) or a binay- and a source-version AND the used options should be documented in a README-file. So everybody can decide for his own which port he uses.
Of course, the httpup approach has some problem as well; packager can disappear, but they're httpup repos are still online. In such cases, we'd need to stop updating from his repo to allow others to maintain his ports... we could require all maintainer to visit an URL with id every month to make sure they're alive.
That's why in my opinion the best solution is to have one point, where everything is avalible: -the information of the port -and the port its self (maybe as gzip file). so you dont have to download a complete repository only for using one port. btw: any comments or improvment suggestions for my database? http://cruxports.tbmnet.de/ (here is a xhtml-preview: http://www.tbmnet.de/tbmnet.php?content=crux_ports_database not yet xhtml strict valid) regards till
participants (6)
-
Daniel Mueller -
Johannes Winkelmann -
Martin Opel -
Simone Rota -
Till Biedermann -
Tilo Riemer