Split Trunk

[Anders F Björklund]

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