As Jay replies in this thread, the missing ports will simply not be part of the new contrib anymore.
I prefer this solution, that encourages the presence only of maintained ports in private collections: I'm not much in favour of providing an additional 'unmaintained' collection (or subset of ports). I guess the idea was to keep those ports around for a while; I sometimes lose interest in port, and drop it from my repo; maybe someone would
This is another reason for which I suggested checking the contributed repsitories as a whole, I like the fact that a contributor would submit the ports in the spirit "Here's a set of ports that I currently use and maintain".
Maybe I'm too afraid the new contrib will become a large pile of junk :) Given that an activation measurement is rather easy to add (be it in the original sync script or externally), I wouldn't try to solve a problem
Hi, On Mon, Feb 07, 2005 at 00:36:25 +0100, Simone Rota wrote: [...] pick it up, if he/she likes it. This would be simplified if 'unmaintained' ports would stay around for a while (a month is definitely enough time for this). Timeline example: X drops port ---> notification --*----> Y picks it up \ \ 30 days ----------> the port is removed Note that there are two components: first, thanks to the notification, interested maintainers will learn about the "free port" and pick it up. Second, it's rather easy to do a 'cp -r /usr/ports/contrib/someport ~/build/upstream'. If a port just fades away, chances are that this happens unnoticed; even if it is noticed, to get the original port, one would have to find the original maintainer, contact him/her and get the port somehow. I'm conviced that small details like this will have a huge effect on the quality of the new contrib collection (but that's of course just an opinion :-)). that doesn't exist yet. I believe that an "update requirement" would mean that only those who want to dedicate a good amount of time will join this project ("uh, I have to guarantee fixed update cycles to join? I don't know..."); the net effect of this is the opposite of what we wanted originally: instead of creating a big collection where to look for ports, we'd add another layer (base/opt, contrib, httpups) and would end up with the very same situation we have now. But before we continue, I guess we should come to some agreement what we actually want ('we' being more than just the three of us, hopefully). Should we schedule an irc meeting to discuss that? Kind regards, Johannes P.S. I started a rewrite of preprep in ruby, which should be both quite efficient and feature packed ;-) -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net