On Wed, 12 Aug 2009 16:14:34 +0200 Jonas Smedegaard <dr@jones.dk> wrote: > Ah. I get it now: A dirty hack intended to be thrown away again right > after its release. Yep. Nasty and quite conceivably, a horrible waste of effort. > I have no interest in rushing dirty hacks to meet a december deadline. > I want to release when ready. Which in the context of emdebian means > that I want to work towards long term goals and only when they make > sense to separate in shorter term milestones does it make sense for me > to include such features in in-between releases. +1 The long term goal has to be a shiny Crush 3.0 that can do everything we need on multiple architectures. Yes, installation may well still be a little awkward for 3.0 but we should aim to have more than just GPE as an environment and more than one or two architectures supported. > >For Crush3.0 or later (after multiarch) we want the same packaging as > >in Debian, that is the main reason of dropping Crush2.0 development. > > If the dream of a Crush 2.0 hinders our vision towards the brighter > future for Crush, then let's kill Crush 2.0. My thoughts precisely. > I somehow got the impression that the impressive list by Neil was > relevant also beyond the release of Crush 2.0. Is that so? It was definitely so. Yes. The list is essentially that which will need to be fixed for 2.0 or if 2.0 is abandoned, will form the basis of the next round of improvements that actually get implemented into 3.0. Of course, some of the tasks (like apt-cross) will be fixed by default in 3.0 because of multiarch support. All the other steps that could rush out a release of 2.0 are hacks that would have to be carefully undone before returning to the list of tasks for 3.0. Not only that, but upgrade paths would need to be considered for those who did try and install 2.0 and wanted to upgrade to 3.0. As it is, there is no upgrade path from 1.0 because 1.0 was so hard to install and only supported a single architecture that has since been dropped - plain old ARM. > Beware that Debian releases are not always major bumps. Or has that > been formalized recently? IIRC it has, yes. Point releases now only happen from the stable-proposed-updates queue, not from testing, and each upload to SPA needs pre-approval from the release team. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp2IdHbpW4vk.pgp
Description: PGP signature