On Oct 3, 2007, at 05:05, Anders F Björklund wrote:
Rainer Müller wrote:
A good reason is, we could adopt new features from base in unstable first and merge them to stable once a new base gets released. For example, removing of "cd" from all ports. Or introduction of compiler.*.
This was what I was thinking about, yes. Or when upgrading one port, but "failing" to upgrade all of the dependencies in the first commit.
Or just to get a little "quarantine" in order to test new releases and updated ports, before introducing them on production machines ?
It sounds great, but are we ready to manage more than one ports tree?
Probably not, as there isn't enough resources maintaining even one tree. I just think it would be a good idea, even if it moved really really slow.
One could start out with a copy of the "archive", and then merge ports one by one from the "trunk" - either manually or maybe just by timer...
I think it's a bad idea, specifically because we're in such a nonoptimal state already. This topic has been discussed on the list before. You may want to look that up in the mailing list archive. Half of our portfiles (2139 of 4300) are currently unmaintained. Even ports that are maintained are not necessarily working properly. How could we in good conscience even declare that the current port collection is "stable"? How would dividing our efforts between stable and unstable branches help us to improve our ports collection faster than we do now? We don't even know which ports currently work and which don't. We don't have any automated build process that tries to build every port on every supported OS & architecture. I kinda feel that would be more useful at this point. We currently get emails or tickets occasionally asking for updates that have already occurred; the user has just forgotten to sync, or the update was just committed and the portindex has not yet been regenerated. If we introduce a quarantine of some sort whereby updates do not immediately appear to users, the frequency of these emails and tickets will increase, and we will have to deal with them, further reducing the amount of time we spend actually fixing the ports. By what mechanism would you suggest that changes move between these two hypothetical ports trees?