Hi again, (Moving the discussion to the ML as I'm moving it far away from the original topic. Please drop #726536 from the Cc list on next reply.)
Daniel Baumann wrote (03 Nov 2013 19:32:31 GMT) : > while we do support running the next stable of live-* on the current > stable distribution (which is what i've said, not the implication to run > 4.x alpha versions), we only recommend people using alpha versions for > development/testing purposes. that's why they are marked alpha and > currently in experimental only. Fair enough. I'm sure the current development & release process has its advantages, but in my experience the result isn't so useful in practice for contributors from downstreams who have a much shorter dev/release/feedback loop than Debian stable. So, I have two proposals that would address my needs and possibly others'. How about making it easier for contributors to backport new features they develop against version N+1 (currently 4.x) to their own (presumably unofficial) version N (currently 3.x) tree they're using in production? As a bonus, I suspect it would make it easier to forward-port into N+1 fixes people develop on version N (e.g. GRML fixes; sure, ideally they would do it in N+1 proper, but I've already explained why it's hard to cover both N and N+1 at the same time, so I understand why they're doing it the way they do). Alternatively, we could ensure the N+1 version in Debian testing is in good shape and usable in production (that's the point of the testing suite anyway): each feature would independently flow into Git, be released as alpha in experimental, and once the most obvious bugs are discovered and fixed, then a given feature could be merged into some other branch, be uploaded to unstable and migrate to the beta version in testing eventually. Of course, the delta would have to be kept as small as possible, else we're just re-introducing the problems that I mentionned earlier. Going this way implies to systematically use topic-branches that can be tested, reviewed and merged independently. That's basically what we do at Tails, and we're putting a release out every six weeks. I'm conscious this adds some overhead, and one loses the linear Git history, but it could avoid the "once feature A is stabilized, there's feature B that comes break other things, and as a result the product seen as a whole is not that often usable for a given complex usecase" effect. Thoughts, other ideas to fix this annoying situation? > wrt/ #726536, clearly, the place to do development is in 4.x and not in > 3.x (or even 3.x within wheezy), which is why i emphasised earlier to do > systemd stuff in 4.x. after all, we do not want to have a 3.x branch > having more features/fixes/$whatever than 4.x. There seems to be a misunderstanding here: I've never proposed to add more features/fixes/$whatever to 3.x than 4.x has. A few weeks ago, you wrote that live-config-systemd 4.x worked, so I was merely proposing to backport these fixes for Wheezy. Anyway, now it appears to be more complicated and I'm giving up. No big deal. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org