The languished meaning of "maintainer" (was: Calling for a new openSUSE development model)

[Jan Engelhardt]

Robert Schweikert wrote in

I believe that an underlying issue to the overall state is the package
maintenance model. Look at any perl or python package in the devel
projects and you'll find tons of people listed as "maintainers" but
almost non of them is a "true" maintainer. Everyone of the listed
"maintainers" is inherited from some parent project and in the end no
one really feels responsible.

Indeed - but: it is the way it is represented in the webui that is
misleading. If you use the command line client, `osc meta pkg`, you get
a *much* more useful and concise set of people - and usually the people
who *really are* responsible. If the so-obtained list is empty, you can
consider the package abandoned already.

That this is an issue is also evident in the increased mail traffic on
the list about lingering SRs.

The problem with lingering SRs has more to do with the
"maintainer"-called role being overloaded - *in prj context*.
I concur with your observation. 22 "maintainers" in games,
42 in devel:libraries:c_c++ don't paint a good picture. But
server:irc's list of 8 also sports the linger problem.

There are a handful of prj-level actions:

- the true maintainer, IOW, "I maintain indeed all packages in here".
This only makes sense for a limited set of develprjs, predominantly
those that deal with a single "software stack" (a group of obviously
related packages). Examples are network:mail:zarafa,
network:telephony:asterisk*. But not games, not d:l:c_c++.

- fallback maintainer: responsibility to accept lingering SRs not
having been accepted by the bspkg maintainer in a handful of days
(3/5/7? maybe settable within the pkgmeta?), provided they meet best
judgment.

- mentor: responsibility to 1. decline *new* packages - sorting out
unsuitable license, ...; 2. approve new packages and perhaps send
corrections immediately afterwards, ...;

These extra roles are merely for self-description of users, and
should simply have the same commit permissions as the current
"maintainer" role do now.

[Jan Engelhardt]

Post by Jan Engelhardt
Robert Schweikert wrote in

I believe that an underlying issue to the overall state is the package
maintenance model. Look at any perl or python package in the devel
projects and you'll find tons of people listed as "maintainers" but
almost non of them is a "true" maintainer. Everyone of the listed
"maintainers" is inherited from some parent project and in the end no
one really feels responsible.

And in other cases, they feel overly responsible -- often without
telling.

I don't mind obvious one-liners, but Base:System/kmod was updated
without making an SR. That way I had no knowing nobody prepared a new
one and had made myself the work to update it to version 9, only to get
a "you must run osc up first" with naturally sufficiently conflicts when
attempting to check in. That sucks.

[Frederic Crozat]

Post by Jan Engelhardt

Post by Jan Engelhardt
Robert Schweikert wrote in

I believe that an underlying issue to the overall state is the package
maintenance model. Look at any perl or python package in the devel
projects and you'll find tons of people listed as "maintainers" but
almost non of them is a "true" maintainer. Everyone of the listed
"maintainers" is inherited from some parent project and in the end no
one really feels responsible.

And in other cases, they feel overly responsible -- often without
telling.
I don't mind obvious one-liners, but Base:System/kmod was updated
without making an SR. That way I had no knowing nobody prepared a new
one and had made myself the work to update it to version 9, only to get
a "you must run osc up first" with naturally sufficiently conflicts when
attempting to check in. That sucks.

Another solution would be to more broadly use osc collab to work on
packages, to prevent stepping on other people toes and duplicate work.

[Jan Engelhardt]

Post by Frederic Crozat

Post by Jan Engelhardt
I don't mind obvious one-liners, but Base:System/kmod was updated
without making an SR. That way I had no knowing nobody prepared a new
one and had made myself the work to update it to version 9, only to get
a "you must run osc up first" with naturally sufficiently conflicts when
attempting to check in. That sucks.

Another solution would be to more broadly use osc collab to work on
packages, to prevent stepping on other people toes and duplicate work.

The collab syntax is currently rather random.
Sometimes you have to add option dashes, sometimes you don't.
Compare:

osc help
osc collab --help

osc someaction security:netfilter iptables
osc collab someaction --project=security:netfilter iptables

osc collab buildsubmit -m "my message"
osc collab comentset pkg "my message"

[Vincent Untz]

Post by Jan Engelhardt

Post by Frederic Crozat

Post by Jan Engelhardt
I don't mind obvious one-liners, but Base:System/kmod was updated
without making an SR. That way I had no knowing nobody prepared a new
one and had made myself the work to update it to version 9, only to get
a "you must run osc up first" with naturally sufficiently conflicts when
attempting to check in. That sucks.

Another solution would be to more broadly use osc collab to work on
packages, to prevent stepping on other people toes and duplicate work.

The collab syntax is currently rather random.

No, it's not random. It might not be completely consistent with the core
osc one, though.

Post by Jan Engelhardt
Sometimes you have to add option dashes, sometimes you don't.
osc help
osc collab --help

Is this an example? If yes, try "osc ls help" :-)

Post by Jan Engelhardt
osc someaction security:netfilter iptables
osc collab someaction --project=security:netfilter iptables

Yes. This is purely historical, back when the collab plugin was only
working for one project. But it's also for convenience reasons, as you
can define your favorite projects and then you can simply do:
osc collab someaction gnome-shell
Which is what most users of collab do.

Post by Jan Engelhardt
osc collab buildsubmit -m "my message"
osc collab comentset pkg "my message"

That's because in commentset, "my message" is a first-class argument (by
that, I mean: it's what the command is about, setting a comment). While
for buildsubmit, "my message" is just a marginally useful commit
message.

That being said, I'm happy to fix usability issues people have with
collab. So far, people had no issue with the UI/syntax, so we kept
things they are.

Cheers,

Vincent