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.
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.
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 ?
--anders
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
