Hi,
Quoting Ian Jackson (2016-12-02 12:43:52)
> Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> > On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote:
> > > 3. Abolish maintainership entirely.
> >
> > This is the obviously right solution.
>
> I can see why this is attractive. But as I say I we need a way to
> deal with disagreements that aren't (for any reason) resolved by
> amicable discussion.
>
> The current resolution to such disagreements is that the "maintainer",
> who is usually the person who produced the previous version, decides.
> This approach has the virtue of stability.
>
> And it is this very rule which is the problem. If you propose to
> solve the stop-energy maintainer deathgrip problem by abolishing
> maintainership entirely, you need to replace it with something.
are you talking about technical disagreements? Isn't that what the TC is for?
In a world without maintainership and multiple people having different ideas
about a technical problem concerning a package, if discussions between them
have lead to no conclusion, would not the TC have the last word about what is
best for the distribution as a whole?
> Otherwise it really will be chaos, with people uploading contra-reverts of
> each others' reverts.
Personally, I doubt that this would happen. In a world without maintainership,
I'd expect anybody doing an upload to do it with the best interest of the
distribution as a whole at heart. If the content of the upload goes against
what other people had in mind, then I'd expect them to discuss and find a
solution. I would not expect the result to be multiple counter-reverting
uploads from the involved parties. That'd just be rude.
> If we simply remove maintainership and say "do as you like" we are actually
> encouraging such hostile behaviour.
I see it differently. If we remove maintainership, then we are telling our
fellow developers that we trust them with the power they wield. So I see saying
"do as you like" not as an encouragement of hostility but as an encouragement
of mutual help and progress.
> I would like to make a counterargument in defence of maintainership. I am a
> believer in stability, and in relying on the judgement of our people.
I believe the same. You are making my argument. :)
> Ownership supports an emotional connection with the work which I think is
> very valuable in a project with many volunteers.
I don't think the emotional connection is lost without the Maintainer field.
The uploader's name will still be in debian/changelog. It will maybe be in the
Uploaders field. It might also be in the dgit history. The "ownership" I feel
by having my name attached somewhere is not lost by allowing more people than
myself to upload.
> Of course there are downsides, but most maintainers - even most sole
> maintainers - in Debian manage their packages well.
I think the same. I think this is the reason why I think that abolishing
maintainership could work well: because the majority of us is doing excellent
work. I believe they will continue to do so whether or not they are given more
privileges over other's packages. In fact, I think that just because most of us
manage our packages well, we'll see an increase in package quality.
It was argued before that if a package is for example team-maintained then that
might mean that because there is no single name attached, nobody feels
responsible to fix bugs in that package and thus a team-maintained package
might loose quality. I don't think that this is the right causality. Sure,
packages are less maintained if nobody cares for them but I don't think that
the "caring" for packages automatically increases by having one's name in the
Maintainer field.
Personally, I don't care for my packages because I have my name in that field
but because I love the software, I love to get more and more acquainted with
the ins and outs of all the technical details the package offers. Because I
love the satisfaction of squashing lintian warnings. Because I love to make
uploads that close lots of bugs. Because I like the satisfaction I get by
knowing that my work just made somebody else's life better. My name will be in
the changelog entries and in the emails I write to the bts. I don't think that
I will take any different amount of care of the packages that currently have me
in the Maintainer or Uploader field if we abolish the former.
> Let me give some personal experience:
>
> I'm the kind of person who always trips over weird edge cases; I have
> high standards of reliability and error handling; and I often feel I
> have a clear vision of what the tool I was using ought to have done.
>
> As a result, over the years and decades I have filed a great many
> bugs. Some of these bugs are extremely obscure. Some of them are
> difficult to fix. Some of them are consequences of erroneous upstream
> design decisions.
>
> In the vast majority of cases my interactions with the maintainers of
> these packages have greatly benefited from the maintainer's ownership
> (in the broadest sense). Maintainers have taken pride in and
> responsibility for the software under their care. They have engaged
> with an open mind. They have engaged to explain my concerns to
> upstream. They have put major rework on their todo lists. They have
> given me good and helpful advice about workarounds.
And I don't think that people will become different if we don't have the
concept of maintainership anymore. They will still be the same people and take
great care of the software that they are interested in.
> (And of course, I have probably become better over the years at engaging with
> more empathy, when I'm filing a bug.)
>
> As a whole, Debian maintainers are not only exceptionally talented. I
> have found them to have great generosity of spirit.
Same here. That's why I agree with Stefano.
> But of course not everyone can be perfect all the time.
Personally, I put myself into the LowThresholdNmu list exactly because I know I
am not either. If you care about my package and you fixed a problem that I am
unable to fix (either because of lack of time or technical expertise) - please
do an upload! It will safe me time and make me happy if you do.
If your upload breaks something or reverts something that was intentionally put
there by me, then apparently I failed at documenting my changes properly or
adding an autopkgtest. I'd say yet another advantage of encouraging
collaboration through abolishment of the maintainership is, that when I then
would change something in the packaging, I would have an even higher incentive
to document my changes or add tests for them. Something that we really should
do more often (think of all our downstreams that use our work) and are not much
encouraged to do right now because it will always be the same person doing the
packaging and upload.
So none of us being perfect all the time - I'd again put this as an argument
for abolishing maintainership entirely.
> I don't think to solve the problem of the small number of hard cases, that we
> need to abolish the institution of maintainership entirely.
I don't think that the main argument for abolishing maintainership is because
of a small number of hard cases. Instead, I think it's because it makes
managing a large number of easy cases much simpler.
> I just want to reframe it a bit, by changing the backstop:
>
> Power relations always colour human interactions. (Power relations
> are about what happens if agreement and consensus cannot be reached:
> they are about who ultimately decides.)
>
> I want to disempower maintainers just a little bit, by providing
> structures, instutitions, or people, who will (in a sufficiently bad
> case, or when asked) look over the maintainer's shoulder.
I am totally with you here. I'd just go a step further as well while we're at
it. :)
Maybe I'm too naive. If I am, could anybody speak up who thinks that they would
take less care of their packages if there is no strict maintainership anymore?
> > we don't have good tools[^] that make it trivial to integrate back changes
> > that have been NMUed by others
> >
> > [^] well, we have dgit, but AFAICT is not really popular yet
>
> If you as a maintainer use dgit, you can integrate an NMU using the dgit
> suite branch even if the NMUer didn't use dgit.
Could you elaborate? I don't find docs on that. And so far I only read about
doing an NMU for a package that uses dgit and not what happens from the side of
the maintainer of that package.
Thanks!
cheers, josch
Attachment:
signature.asc
Description: signature