[clc-devel] Ports reorganisation?
jw at tks6.net
Fri Jan 9 09:40:42 UTC 2004
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:
> 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
> [*** 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
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.
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").
> [*** 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
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
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"
> [*** 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 at tks6.net
Biel, Switzerland http://jw.tks6.net
More information about the crux-devel