[opensuse-factory] The languished meaning of "maintainer" (was: Calling for a new openSUSE development model)
Robert Schweikert wrote in http://lists.opensuse.org/opensuse-factory/2012-06/msg00489.html :
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2012-06-21 18:46, Jan Engelhardt wrote:
Robert Schweikert wrote in http://lists.opensuse.org/opensuse-factory/2012-06/msg00489.html :
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le vendredi 22 juin 2012 à 23:51 +0200, Jan Engelhardt a écrit :
On Thursday 2012-06-21 18:46, Jan Engelhardt wrote:
Robert Schweikert wrote in http://lists.opensuse.org/opensuse-factory/2012-06/msg00489.html :
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.
--
Frederic Crozat
On Monday 2012-06-25 10:18, Frederic Crozat wrote:
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" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 25 juin 2012, à 14:40 +0200, Jan Engelhardt a écrit :
On Monday 2012-06-25 10:18, Frederic Crozat wrote:
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.
Sometimes you have to add option dashes, sometimes you don't. Compare:
osc help osc collab --help
Is this an example? If yes, try "osc ls help" :-)
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.
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 -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Frederic Crozat -
Jan Engelhardt -
Vincent Untz