ANN: Closing AC

[Jakub Piotr Cłapa]

Tomasz Pala wrote:
> On Sun, Dec 11, 2005 at 21:29:59 +0100, Cz at rny wrote:
> 
>> These two alternatives are where we should search for a way out. Or we  
>> hold an enviroment to build patches and so on (the question is how long  
>> and how many steps back).
>>
>> The '???' alternative sound great - but we have to invet it :>
> 
> It already is - distro lines.

But it doesn't really work. Ra is stable but hopelessly old. Ac is newer 
but not stable. The releasing process is painful.

We can have ready and test. Ready could be then used for bug-fixes and 
critical updates before the whole new environment is complete.

This way we could have a constantly current distro with snapshots that 
are retrospectively tagged as stable (with ISO releases and FTP 
directories) and can be used on servers and with updates that apply 
almost without a problem (comparing to what we have with Ra->Ac 
migration) because all the developers would try to make them better 
(contrary to the current state, when all developers are using Ac or Th 
and almost none of them are bothered by Ra update).

The true idea behind this whole proposal is to sanction the process 
that's already taking place in Ac. To stop thinking about the release 
and focus on making infrastructure and architectural changes [1] to ease 
the continuous development process that is already a taking place.

It won't solve all our problems and double the effect halving the 
required effort at the same time but I think it could work better than 
the current scheme. It would  also make PLD different from other distros 
giving more stress on the constantly up-to-date aspect of it. No one 
have ever proved that this is a bad idea and what's more nobody I am 
aware of event tried it so maybe it's worth trying.

[1]
- FTP revisions and their tagging (so you can always downgrade or simply
   use an older version until you gain confidence that newer is better)
- giving developers more access to the builders (as was proposed by
   mmazur for Th)
- adding things like automatic* filesystem snapshooting based on UnionFS 
allowing you to reverse all changes done to a filesystem (or a part of 
it) to fix after broken upgrades

* it could be triggered automatically by poldek (configurable) or 
manually before large administration changes

-- 
Regards,
Jakub Piotr Cłapa