On 18/11/15 11:04 PM, Michael . wrote:
> It is highly unlikely Debian will move alpha software into Stretch
> when it becomes stable. Jessie is 6 moths old so Testing freeze is
> possibly 12 months away with Stretech's release approximately 6 months
> after that. I can only hope Live Wrapper is mature by then.
Don't confuse upstream stage of software development with
release-readiness from Debian's perspective. There can be release
critical bugs on 'stable release' software that threatens its removal as
the next Debian release nears, and conversely, 'alpha stage' software
can be released, so long as it has no release critical bugs.
packages.debian.org tells me live-build 5.0~a11-1 is in Stretch. Unless
matters worsen between now and Stretch's release (e.g. RC bugs are filed
on it and nobody steps up to fix them), it *will* release with Stretch.
You do not need to speculate on what Debian will or will not do in the
> May I ask then what was not sane, what was fragile, and what was
> unofficial, with regards to Live Build?
Now you're twisting my words. live-wrapper's goal to provide a positive
contribution to the Debian project is not mutually exclusive with
live-build continuing to make a positive contribution to the Debian
project. My statement was in support of the value of their work, not a
statement of the lack of value live-build. I think live-build has served
a lot of people well for a long time. It has its quirks, and has not
always been easy to keep up with, as the development process has
introduced a constant stream of incompatibilities with prior versions.
However, as a community, we've dealt with that, and we have nevertheless
built a lot of awesome things with it.
> >So your answer to moving those discussions quicker is to push the
> >live-wrapper developers away where they won't bother you?
> Push them away so they wont bother me?
Yes. At the beginning of this thread you said that live-wrapper
discussions were unwelcome here and they should be taken elsewhere.
> I've tried to get answers to simple questions, you know answers like
> "yes we did provide patches and they were ignored-rejected-whatever".
> If this has, as you appear to be saying and the other team actually
> did say, "coming for a long time" the logistics of this should have
> been worked out already. Having these discussions after the fact
> indicates a whole heap of poor planning.
I understand you find communication about these matters difficult and
frustrating. I share your frustration. However, the outcome (that Daniel
quit) was not planned nor desired. From what I can see, it was intended
that live-wrapper be developed in parallel with live-build until it
reached maturity and could be used by Debian CD to ultimately replace
live-build. It appears to have been inevitable in the Debian CD team's
eyes that they would have to write something to accommodate what they
saw as the flaws in live-build, but I don't see that it was inevitable
that live-build development had to cease. That was a decision one person
made unilaterally and we now have to deal with that.
> >Sorry, I just don't see the need for this. I don't see Debian making
> >"statements" in other cases where upstreams have given up and Debian has
> >moved on. At least not unless it's a fairly big piece of infrastructure
> >with broad impact on the project and a clarifying statement really is
> >necessary (like libc6). I don't think that's the case in this situation.
> >I rather think it will work out organically instead, from the people
> >doing the work from here on to improve the toolset, and will not be
> >something that comes down as a decree from the top.
> I must have misunderstood the importance to Debian of having a "Live"
I didn't say it wasn't important for Debian to have one. I only spoke to
the relative importance of libc6 vs. live-build and therefore what sort
of official Debian response there needs to be in this situation. Debian
contains lots of important software, including live-build. Debian does
not issue official statements about upstream changes for many of them.
In the specific case of eglibc, a statement was warranted and therefore
issued because that had broad impact on the project as a whole. I don't
believe live-build is in the same category because it is a broadly used
piece of infrastructure that many other Debian packages depend upon. But
I'll reiterate, this is just my personal opinion.
> >What you officially do with your project is up to you. I think it's
> >pretty clear by your own statement that live-wrapper is not ready for
> >you to use, so you ought to continue using live-build for now. What real
> >blocker stands in your way of continuing to use it if it has been
> >working well for you?
> Ben, if Live-wrapper is really for me to use please tell me what dist
> it is currently available in so I can use it? I've just done a search
> of Debian Packages and it isn't listed so it isn't ready for me to use.
Didn't I just agree with that? So continue to use live-build for now,
and continue to help improving it. If-and-when live-wrapper reaches
maturity you may want to try it, but until then I see no reason you have to.
> The blocker for me to use Live Build is a rather simple one that it
> appears the project is dead in the water. There is no lead, no further
> development (yes patches can be applied but Live Build 5 is alpha
> software and as such I can't see it getting into Stable when Stretch
> becomes stable, even if that is approximately 18 months away).
It is in Stretch already, and there are no RC bugs filed on it. If the
community of users and developers surrounding live-build want to
preserve this valuable software, we need to team together and continue
supporting it. If we fail to do that, it is not on Debian for the
failure of live-build to continue moving forward, it's on us, the
live-build user/developer community for not caring sufficiently to keep
> Thanks for your responses, they were informative and very much
You're welcome. I hope in coming days these tensions will subside, and
we will continue to work on these two projects side by side, on
live-build to help keep it patched and release-ready for Stretch (as I
said, it's already in good enough shape that it *is* in Stretch, and
there's no reason that shouldn't continue to be the case if we care
about it) and live-wrapper to help it reach maturity so that we can have
an alternative that addresses the issues it has set out to address.