[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Crush 2.0 abandoned

On Wed, 12 Aug 2009 15:05:01 +0200
Jonas Smedegaard <dr@jones.dk> wrote:

> Are Crush releases directly tied to Debian releases, with whatever 
> features included that happen to be implemented at time of Debian 
> release?

Yes - and the tie is quite tight, for both Emdebian Crush and Emdebian
Grip. The reasons are:

1. The release freeze in Debian works in our favour by stabilising
critical packages like gcc, glibc, busybox etc. This gives us time to
actual fix the cross-builds of those packages and test the results
*without* a new version arriving and breaking the builds again.

2. We don't need to create an Emdebian release team and we have quite
enough to do without duplicating the release process.

3. The release freeze also provides time for testing installation
problems etc. just at the time when others are doing the same for the
Debian installer.

4. Emdebian has the same suite structure as Debian and in order to
manage transitions, we need to keep in sync with the Debian suites for
things like unstable->testing transitions (britney). Outside a release
freeze, transitions are constantly being started and completed -
immediately that a release freeze is over, a mass of new transitions
start and unstable is horribly broken for a period of time. Either we
release in that period of calm during the Debian release freeze or we
miss the boat entirely - we simply don't have the resources to do

5. Releasing early is counter-productive - release critical bugs are
still being fixed in Debian, the installer is still being updated and
improved, the release notes are being finalised (and we get a chance to
be mentioned in them) - we can adopt and adapt all of these things into
the Emdebian release but we miss that chance if we release weeks before
the official Debian release is made.

6. It makes it possible to use packages from normal Debian on an
Emdebian system - this is obviously easier with Grip but with the
changes from the CodeAudit, it should be possible in Crush 3.0 as well.

7. Emdebian is, after all, the distribution created by the Embedded
Debian project, an official sub-project of Debian. We are part of
Debian, we should keep in step with Debian.

Hmmm, that's another list that probably needs to go on the wiki.

> ...and that the detailed features you mention above are just some that 
> you _believe_ are likely to get implemented in time for those next 
> Debian releases?

Yes - from watching debian-devel etc.
> Or is it that Crush releases are _loosely_ tied to Debian releases - 
> i.e. released no earlier than Debian releases, but possibly much later, 
> depending on how soon wanted features are implemented?

Much later is a huge problem - the moment that the first packages start
migrating from the newly unfrozen unstable into testing, we have
immense problems with our own builds, testing and the rest. Making an
Emdebian release anything more than 10 days after Debian unstable is
unfrozen is going to be horrible - especially as unstable is at it's
most broken state immediately after it is unfrozen after a Debian

It comes down to the same problems - we don't have enough people or
enough time to manage our own releases and we need to base transitions
on the work done within Debian, so we cannot afford to attempt a
release whilst Debian is not in freeze.

> >Current workflow for crush, download a package from debian, patch,
> >build, fix and rebuild.

(That's all wrapped up in a single script: emsource and the
autobuilders will handle most of the work.)

> Now, patches does not apply. So, I was just
> >suggesting, in case somebody wants to work on crush 2.0, to have
> >separated files for cross instead patching Debian one, so i assume that
> >patches can be useful in longer term in an automated build system.
> This still sounds to me like you want to completely ignore Debian 
> packaging and instead use a completely separate packaging directory.
> Yes, if completely ignoring ./debian then patches won't fail.  But that 
> approach will also not reuse any of the Debian packaging efforts.  I got 
> to be misunderstanding somethong here - I *know* that you are more 
> clever than that ;-)

These kind of hacks are why I decided Crush 2.0 was simply out of
reach. Making such choices just to get Crush 2.0 out of the door will
come back and bite! There is no point releasing Crush 2.0 in haste - if
it isn't better than 1.0, don't release it at all. Wait for 3.0.

(Better in this sense does not mean merely updated to the same package
versions as Squeeze. Better means easier to install, easier to test,
more architectures, more packages, better suited to a wider range of
hardware etc. In a way, Crush 1.0 was almost a single-machine release
- it worked on balloon3 and that was about it, everything else was a
real struggle.)

Despite all the discussion here since I posted my original
announcement, I've seen nothing that indicates that there are enough
people with enough free time to breach the learning curve and put Crush
2.0 back on track. I did suspect as much at the start - otherwise I
would have simply asked for help with 2.0 instead of abandoning it

I strongly recommend that everyone who was thinking about Crush 2.0
puts their efforts into Crush 3.0 instead. The foundations of 2.0 are
just too shaky and all the effort could be completely wasted as the
changes needed for 3.0 are likely to be easier to implement from the
current base than they would be *after* all these hacks are implemented
to get 2.0 into anything like a release candidate.

In other words, I have a horrible feeling that spending time on Crush
2.0 will make it harder to release Crush 3.0 and that we will be able
to make a useful, successful release of Crush 3.0 *ONLY* if we skip the
Crush 2.0 release entirely. By all means work on Crush to move things
along, but lose the haste by dropping the 2.0 release. Instead, start
*now* to make changes within the Crush build system that will support
the final multiarch system with xcontrol or whatever else we decide to
create to deploy functional changes in packages in Crush 3.0. 

Let's not taint the project with a horror show of Crush 2.0. Better to
skip Crush 2.0 than to let Crush 2.0 be worse than Crush 1.0. Things in
Debian just are not ready for Crush 2.0 and I'm sure we will all regret
it if Crush 2.0 is pushed out in haste.

It isn't ideal, it isn't a nice thing to do but it is the NECESSARY
thing to do.


Neil Williams

Attachment: pgpgQKq7oZrIF.pgp
Description: PGP signature

Reply to: