Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
- Date: Mon, 22 May 2017 17:10:26 +0100
- From: Jonathan Dowland <jmtd@xxxxxxxxxx>
- Subject: Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 03:25:38PM +0100, James Clarke wrote:
> On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote:
> > Excellent, this is a great start, and seeing "Michael Stapelberg" for me is an
> > indication of quality.
emphasis on *start*
> You say that, but this is incredibly biased. Even he admits that in the
> colour choice.
I was completely ignoring the colour choices and implementation language.
> that for the sbuild path, schroot is completely missing
Indeed there are a lot of omissions. I think the next step, whether this
is the basis for what goes next, or not, would be to get the source of
this picture (or another) into a version control system so it can be
iteratively and collaboratively improved.
[ Stapelberg via James Clarke ]
> > I propose to eliminate complexity in Debian by deprecating the
> > pbuilder toolchain in favor of sbuild.
> Now, I am not necessarily against simplifying workflows, but choosing
> one to rule the all arbitrarily because you prefer the language it's
> written in is not the way to go about it.
Language should be a factor, as there are practical considerations that can't
be avoided, independent of personal preferences – but I got the impression
that he was not coming to this conclusion soley on the basis of implementation
language anyway, nor soley in terms of his own preferences for implementation
> There are also benefits to having a variety of implementations; they behave
> slightly differently, sometimes not implementing policy in the same way, and
> this can be a good thing, allowing policy to be clarified, or finding
> mistakes in the other builder, or just exposing flaws in your package.
These are good points. However, considering just these points in isolation,
the "secondary" implementation(s) would not need to be something that was
actually geared towards real users, or advertised as such.
> I'm not trying to sell pbuilder over sbuild here though; there are also many
> ways in which sbuild is better than pbuilder.
I am not (yet) familiar enough with either of them (or the other dozen or so
similar tools for the same job) to come to a conclusion on what I think would
be the correct number/recommendations for Debian contributors, but I am of the
initial opinion that there are too many. I've heard a lot of good things about
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.