Split Trunk

[Weissmann Markus]

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/