Re: Bikeshedding
On 15358 March 1977, Stefano Zacchiroli wrote:
I'm not fundamentally against that being a "must", but we should just be
aware that there might be some use cases that we'll end up sacrificing
in order to make such a unification of source control hosting possible.
I agree with your analysis here: there is a clear trade-off between
flexibility in package maintenance practices and uniformity.
Yes.
I know well where I'm placed on that trade-off: I'd take uniformity
every day. I'm convinced Debian's inability to impose one way of
maintaining packages is holding us back in our ability to implement (by
the means of semi-automation) archive-wide changes and is also setting
the bug for newcomers unreasonably high.
I have been on the side of "we are fine, you need to learn stuff, go and
do it". I am still on that, but much moving to "It ought to be enough to
learn one way and style, not a trillion different little ones".
This is scary in many ways, starting with "Oh gosh, 1k other people have
access to MY packages?" and "Uh what, I am able to modify all them other
30k packages, why do you trust me with that" and is entirely different
to what we do now (mostly, collab maint exists, I know).
What I'm trying to determine with this sub-thread is which candidates,
if any, are willing to take a courageous stance on this matter and, if
so, how will they go about it.
For now, I'm understanding that you're more inclined than Ganneff to
take steps to uniform package maintenance practices, but at the same
time you want to retain some uniformity. So I'm still at loss at what
*concrete steps* you will take to increase uniformity throughout the
archive.
I know I've not given exact steps on how to go. Discussion, possible GR.
That is vague, I understand. It is too broad a thing to nicely formulate
something now and stick with it. But I wouldn't say I am not prepared to
take steps to uniform stuff. Though I can list some actionable items, if
that makes it feel more real.
First off it needs to get discussed at a proper venue, -devel or
-project, not -vote. It also needs to have talks with DSA and salsa
maintainers, as it will mean a noticable load increase for that service
which may mean a change of the way it is setup (split over machines).
If that all works out positively, it needs -policy involved, as that
document needs to have paragraphs talking about it.
And then it will end up a GR, presenting the worked out solution and
policy change to the developers and let them decide for or against it.
And working that out will take time. While its simple to state "It all
must be there", there are various exception to the rule to be
considered, as usual. And get into it...
--
bye, Joerg
Reply to: