On 04.10.2007, at 08:54, Anders F Björklund wrote:
Ryan Schmidt wrote:
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.
Took a quick look, but it was mostly about "are you guys crazy". Will take another look...
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?
Actually I didn't use the terms "stable" and "unstable" (I think those were from Fink), I used the terms "release" (since the term "archive" means that it is frozen) and "development" (or the SVN term of "trunk").
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.
It's much easier to do packaging and testing, when the rate of change slows down. The automated build and packaging process is being revised now (using it to build RPMS), and that is very useful to have either way.
This is great. I think we can talk about splitting the tree as soon as this features is finished and we have a build-server that reports about build errors.
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.
Impatient or out-of-date users will occur either way, the easiest path to help them is probably have an updated ports list for easy viewing - such as a web page with versions and recent updates.
The out-of-date users will be far less if we provide RPMs. The impatient ones are often also those who find the bugs in the first place.
By what mechanism would you suggest that changes move between these two hypothetical ports trees?
"Release Engineering". Eventually, someone will have to take a look at it. But maybe just not today ?
I'd prefer to combine this job with an automated build. This will make this tasks much less error prone and less time consuming. -Markus --- Markus W. Weissmann http://www.mweissmann.de/