Bug#726536: live-* development & release process: making contributions easier [Was: Bug#726536: Processed: bts]
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
Reply to: