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 otherwise. 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 release. 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 entirely. 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpgQKq7oZrIF.pgp
Description: PGP signature