Split Trunk

[Ryan Schmidt]

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?