Maintainer model clean up

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Maintainer model clean up

Robert Schweikert-6
Hi,

This is also related to the "Coolo needs help thread".

During osc12 we had various discussions related to the topic of getting
the distribution out the door and how we can get there within the
release schedule that we had agreed to a while back. Part of this
discussion are the two sessions I had the opportunity to lead, both are
available on youtube opensusetv, if you are interested in this topic
please go and watch these sessions, as well as Stephan's session, also
on youtube. Unfortunately we did not have video equipment in the BoF
session.

The basic proposal is, and this received general agreement at osc12,
that we will move toward changing the model as proposed in the session.
This implies the following:

- In the web UI one will no longer see inherited project maintainers on
the package page, only the "true" package maintainers. (Inherited
"maintainers" will be hidden in an expandable tree)

- We will collect information about all packages in all devel projects
that feed factory. We will generate a list of packages that have no
maintainer, and a list of packages that need help, i.e. a package that
has fewer than 5 maintainers. In addition we will list packages that
have more than 5 maintainers and try to encourage maintainers from those
packages (to get the number to 5) to take on packages that need help.

- We want to clean up the devel project maintainer list to a ratio of
10/500 packages with a max of 25.
   ~ In many cases package maintainers in a given project do not care
     about all the other packages in the project, yet they are on the
     project maintainer list.
   ~ Also many people have their Hermes notifications disabled as they
     get too many messages about packages they do not care, hopefully
     with the changes more people will re-enable their Hermes
     notifications (more on this below)

- We would like to see a notification on the package page if the package
fails to build in factory

- Would like to see package build status information on the factory
status page about the status of the package in it's devel project.

- Having the monitor page and the status page presented in the current
form is confusing, we need to somehow merge the information.

- It would be really nice if there were some kind of policy engine that
could enforce the "no more than 5 per package" and the "no more than 25
project maintainers" policies.
   ~ now OBS is not just for openSUSE, thus this cannot be hard coded
     into the OBS code, thus this is potentially a lot of work.

- We would like to have some kind of rating system on the devel projects

- We will produce guidelines for package and product maintainers
outlining what is expected.
   ~ These guidelines are not hard rules, but provide help to new
     people stepping in to define the role they are comfortable
     with. There appears to be a problem that the complete void of
     guidelines in this area leads to paralysis and people just do not
     know what to do if they want to help. We have documents how to
     package, these guidelines will be a hopefully short list of
     "what is expected".

These are the rough outlines of the "plan". Obviously there is work to
be done and the OBS team already has plenty to do. It is up to me to
document in more detail the requirements/use case before a potential
timeline can be developed. I will also start a wiki page attempting to
define the various roles in the devel process and then opening that up
for discussion once the basics are in place.

Now to a couple of counter points.

- Yes we will step on some people's toe, sorry. Meaning if you get
removed as project maintainer from a devel project and you really really
want to be a project maintainer you are probably not going to be happy.
Please do not take it personal and get yourself added back to the
project. Preferably you would find one of the project maintainers that
remained, by chance and chance alone, and get that person to drop of the
list. Chances are you will find someone willing to "make space for you"
   ~ Sorry, but this process has to be somewhat arbitrary due to the
     large number on the various devel projects.
   ~ Please be not offended, there is no vicious intent, just the intent
     to help the project grow and scale better.

- Yes, the "rules" are changing, and if you maintain a package that is
also in factory there will now be some expectations
   ~ In the end we all should have the same goal, create a quality distro
     in the time frame we promise, thus this should really not be a big
     deal

Before I close this rather long e-mail (sorry) I have a kind of survey
question. I would like to have the hermes settings of package
maintainers reset "automatically" as we move through the house keeping
project such that package maintainers get notification of build failures
of their packages. I realize many people have these turned off today,
but again, this is probably due to the number of notifications due to
the project maintainer mails that most people do not care about.

OK, before I write another couple of pages about this subject I'll stop
here.

Thanks for your attention, please no flaming, bitching and moaning.
Great ideas and help are welcome.

Later,
Robert

--
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
[hidden email]
[hidden email]
781-464-8147
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Cristian Morales Vega-3
On 26 October 2012 09:16, Robert Schweikert <[hidden email]> wrote:

> - Yes we will step on some people's toe, sorry. Meaning if you get removed
> as project maintainer from a devel project and you really really want to be
> a project maintainer you are probably not going to be happy. Please do not
> take it personal and get yourself added back to the project. Preferably you
> would find one of the project maintainers that remained, by chance and
> chance alone, and get that person to drop of the list. Chances are you will
> find someone willing to "make space for you"
>   ~ Sorry, but this process has to be somewhat arbitrary due to the
>     large number on the various devel projects.
>   ~ Please be not offended, there is no vicious intent, just the intent
>     to help the project grow and scale better.

Meaning that if you don't care about a project you are a maintainer
of... NOW it would be a good moment to remove yourself from the list.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Guido Berhoerster-6
In reply to this post by Robert Schweikert-6
* Robert Schweikert <[hidden email]> [2012-10-26 10:16]:
> - We will collect information about all packages in all devel
> projects that feed factory. We will generate a list of packages that
> have no maintainer, and a list of packages that need help, i.e. a
> package that has fewer than 5 maintainers. In addition we will list

Not sure if I understand that right, a package that has fewer
than 5 maintainers "needs help"? If so, that seems completely
arbitrary and even absurd, as this totally depends on the
complexity of the package and existing maintainer and probably
reinforces the very problem you're trying to solve (nobody having
a sense of ownership and feeling responsible) in a lot of cases.

Apart from that I'm missing some kind of more formal orphaning
process from your proposal, I think that's part of the issue when
maintainers go missing and a package becomes unmaintained without
anyone noticing (at least until it fails to build on Factory). We
should encourage people to announce it when they are no longer
able to maintain a package (which rarely happens) and have some
process for orphaning by non-maintainers when a maintainer becomes
unresponsive.
--
Guido Berhoerster
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Cristian Morales Vega-3
In reply to this post by Robert Schweikert-6
On 26 October 2012 09:16, Robert Schweikert <[hidden email]> wrote:
> - We want to clean up the devel project maintainer list to a ratio of 10/500
> packages with a max of 25.

What about project "bugowner"s? Why is not every maintainer a
bugowner? There will be limits for bugowners?
I just added myself as bugowner of multimedia:libs so I would get
added CC to the bug reports. But I tested and I actually get assigned
to them and sbrabec, the previously only bugowner, gets CC. I see no
way to change this, it seems to be related to the nickname.

It seems to me that every maintainer should get added CC to the bug
reports. If there is any "bugowner" role at all it should be just to
specify a "main maintainer" that would be the one that gets them
assigned.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Jan Engelhardt-4
In reply to this post by Robert Schweikert-6

On Friday 2012-10-26 10:16, Robert Schweikert wrote:
>
>- We will collect information about all packages in all devel projects that
>feed factory. We will generate a list of packages that have no maintainer, and
>a list of packages that need help, i.e. a package that has fewer than 5
>maintainers.

A package should not strictly need five people to be considered
maintained. If it did, we would be back to "someone else will
probably do it" type of problem.
Especially for the smaller packages.

>~ In many cases package maintainers in a given project do not care
>  about all the other packages in the project, yet they are on the
>  project maintainer list.

Yes; this is because the prj maintainer is the one equipped with
the accept-new-package power.

>~ Also many people have their Hermes notifications disabled as they
>  get too many messages about packages they do not care, hopefully
>  with the changes more people will re-enable their Hermes
>  notifications (more on this below)

Conversely, Hermes also suppresses certain SRs:
 https://bugzilla.novell.com/show_bug.cgi?id=739335
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Jan Engelhardt-4
In reply to this post by Cristian Morales Vega-3
On Friday 2012-10-26 11:24, Cristian Morales Vega wrote:

>On 26 October 2012 09:16, Robert Schweikert <[hidden email]> wrote:
>> - We want to clean up the devel project maintainer list to a ratio of 10/500
>> packages with a max of 25.
>
>What about project "bugowner"s? Why is not every maintainer a
>bugowner?

I like how bugowner is separate from the maintainer;
that way, I can designate someone else to be the
"first-level support" person for bugzilla entries.
Like, in X11:RemoteDesktop:x2go.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Michal Vyskocil-2
In reply to this post by Robert Schweikert-6
On Fri, Oct 26, 2012 at 04:16:18AM -0400, Robert Schweikert wrote:
> Hi,

Hi Robert,

>
>
> - We will collect information about all packages in all devel
> projects that feed factory. We will generate a list of packages that
> have no maintainer, and a list of packages that need help, i.e. a
> package that has fewer than 5 maintainers. In addition we will lista
> [snip]

I assume that **most** of packages has less than 5 maintainers!
Personally, I'd not limit the lower bound - something between 1-5 seems
to be OK. For biggest numbers, OBS has to be cleanup, or packages has to
be moved to an another devel project.

> packages that have more than 5 maintainers and try to encourage
> maintainers from those packages (to get the number to 5) to take on
> packages that need help.
>
> - We want to clean up the devel project maintainer list to a ratio
> of 10/500 packages with a max of 25.
>   ~ In many cases package maintainers in a given project do not care
>     about all the other packages in the project, yet they are on the
>     project maintainer list.
>   ~ Also many people have their Hermes notifications disabled as they
>     get too many messages about packages they do not care, hopefully
>     with the changes more people will re-enable their Hermes
>     notifications (more on this below)
>
> - We would like to see a notification on the package page if the
> package fails to build in factory
>
> - Would like to see package build status information on the factory
> status page about the status of the package in it's devel project.
>
> - Having the monitor page and the status page presented in the
> current form is confusing, we need to somehow merge the information.
>
> - It would be really nice if there were some kind of policy engine
> that could enforce the "no more than 5 per package" and the "no more
> than 25 project maintainers" policies.
25 people per project (given the huge number of projects we have) seems
to be as a big number! Do you have an example, where it can make a
sense?

So can we be more strict, lower the default numbers and increase them
upon the request? I assume lower numbers can fit a majority of devel
projects we have.

>   ~ now OBS is not just for openSUSE, thus this cannot be hard coded
>     into the OBS code, thus this is potentially a lot of work.
>
> - We would like to have some kind of rating system on the devel projects
>
> - We will produce guidelines for package and product maintainers
> outlining what is expected.
>   ~ These guidelines are not hard rules, but provide help to new
>     people stepping in to define the role they are comfortable
>     with. There appears to be a problem that the complete void of
>     guidelines in this area leads to paralysis and people just do not
>     know what to do if they want to help. We have documents how to
>     package, these guidelines will be a hopefully short list of
>     "what is expected".
>
> These are the rough outlines of the "plan". Obviously there is work
> to be done and the OBS team already has plenty to do. It is up to me
> to document in more detail the requirements/use case before a
> potential timeline can be developed. I will also start a wiki page
> attempting to define the various roles in the devel process and then
> opening that up for discussion once the basics are in place.
>
> Now to a couple of counter points.
>
> - Yes we will step on some people's toe, sorry. Meaning if you get
> removed as project maintainer from a devel project and you really
> really want to be a project maintainer you are probably not going to
> be happy. Please do not take it personal and get yourself added back
> to the project. Preferably you would find one of the project
> maintainers that remained, by chance and chance alone, and get that
> person to drop of the list. Chances are you will find someone
> willing to "make space for you"
>   ~ Sorry, but this process has to be somewhat arbitrary due to the
>     large number on the various devel projects.
>   ~ Please be not offended, there is no vicious intent, just the intent
>     to help the project grow and scale better.
On the other hand, users have to be informed about the change via email,
which will give them needed information and describe steps needed for
getting the maintainership back if they're still interested ...

>
> - Yes, the "rules" are changing, and if you maintain a package that
> is also in factory there will now be some expectations
>   ~ In the end we all should have the same goal, create a quality distro
>     in the time frame we promise, thus this should really not be a big
>     deal
>
> Before I close this rather long e-mail (sorry) I have a kind of
> survey question. I would like to have the hermes settings of package
> maintainers reset "automatically" as we move through the house
 ... or how to turn the hermes off again ;-)

> keeping project such that package maintainers get notification of
> build failures of their packages. I realize many people have these
> turned off today, but again, this is probably due to the number of
> notifications due to the project maintainer mails that most people
> do not care about.
>
> OK, before I write another couple of pages about this subject I'll
> stop here.
>
> Thanks for your attention, please no flaming, bitching and moaning.
> Great ideas and help are welcome.
OK, so there are my few cents
 
## Make default maximum numbers lower and increase them per-project/per-request

## http://s.kulow.org/fs-$user is awesome!

Please add such link to the main page of webui (My work?). And continue
with reminder emails

## Make the process of changing devel project easier

atm, you have to
    1) sr to the new project
    2) wait-till-accepted
    3) issue changedevelrequest
    4) wait-till-accepted
    5) merge things from old and new devel project together
    6) issue the deleterequest to Factory
    7) issue the deleterequest to the old devel project

which is horrible and most of people won't do it

My proposal is that changedevelrequest can do all the work internally,
once went through normal checkin process (review-team(?), factory-maintainers)

Or let coolo write the script do it all ;-)

## Lower the number of devel projects in OBS

The good start is to sort them with a number of project maintainers -
those are propably pointless and shall be killed. Yes, I'm targetting
the Base:System.

I did a bit shell scripting and those are the "worst" projects

Base:System;56
Education;42
devel:libraries:c_c++;42
network;30
YaST:Head;29
server:mail;27
science;27
network:utilities;25
server:monitoring;24
security;24

The complete list is attached, but it's obvious, that 25 limit is too
high

## Monitor

We need to monitor an activity of maintainers to check, if they are
still active or not. So have a list of projects/packages did not
accepting requests for a long time, list of packages are not touched for
a long time and so - but this is probably something for a limited number
of eyes.

Regards
Michal Vyskocil

devel-projects-per-people.txt (2K) Download Attachment
signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Philipp Thomas-3
On Fri, 26 Oct 2012 14:47:12 +0200, Michal Vyskocil
<[hidden email]> wrote:

>I did a bit shell scripting and those are the "worst" projects
>
>Base:System;56
>devel:libraries:c_c++;42

I'd gladly give up the maintainership for most projects *if* there was
another way of acquiring the right to create new packages. For
instance it would be more complicated to do the package split for
util-linux without that right.

>We need to monitor an activity of maintainers to check, if they are
>still active or not. So have a list of projects/packages did not
>accepting requests for a long time, list of packages are not touched for
>a long time and so - but this is probably something for a limited number
>of eyes.

+1 as it is IMHO vital to ring a bell when things like submit requests
are silently rotting away.

Philipp
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Stephan Kulow-3
Am 26.10.2012 20:26, schrieb Philipp Thomas:

> On Fri, 26 Oct 2012 14:47:12 +0200, Michal Vyskocil
> <[hidden email]> wrote:
>
>> I did a bit shell scripting and those are the "worst" projects
>>
>> Base:System;56
>> devel:libraries:c_c++;42
>
> I'd gladly give up the maintainership for most projects *if* there was
> another way of acquiring the right to create new packages. For
> instance it would be more complicated to do the package split for
> util-linux without that right.
>
With that model there will be responsive project maintainers who can
help you accepting SRs. So you split util-linux in your branch and then
submit to the main project.

Greetings, Stephan

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Jan Engelhardt-4
In reply to this post by Cristian Morales Vega-3

>Meaning that if you don't care about a project you are a maintainer
>of... NOW it would be a good moment to remove yourself from the list.

I dropped myself off filesystems, games, Linux-PAM.
Now, it's your turn :)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Cristian Morales Vega-3
In reply to this post by Robert Schweikert-6
On 26 October 2012 09:16, Robert Schweikert <[hidden email]> wrote:
> - We will collect information about all packages in all devel projects that
> feed factory. We will generate a list of packages that have no maintainer,
> and a list of packages that need help, i.e. a package that has fewer than 5
> maintainers. In addition we will list packages that have more than 5
> maintainers and try to encourage maintainers from those packages (to get the
> number to 5) to take on packages that need help.

I guess during feature freeze it's not the best moment to start
playing with maintainership rights. But there is any progress about
all this "Maintainer model clean up"? I am specially interested in
those lists you mentioned.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Robert Schweikert-6
On 01/23/2013 09:45 AM, Cristian Morales Vega wrote:

> On 26 October 2012 09:16, Robert Schweikert <[hidden email]> wrote:
>> - We will collect information about all packages in all devel projects that
>> feed factory. We will generate a list of packages that have no maintainer,
>> and a list of packages that need help, i.e. a package that has fewer than 5
>> maintainers. In addition we will list packages that have more than 5
>> maintainers and try to encourage maintainers from those packages (to get the
>> number to 5) to take on packages that need help.
>
> I guess during feature freeze it's not the best moment to start
> playing with maintainership rights. But there is any progress about
> all this "Maintainer model clean up"?

Yes, there is progress. On a large number of projects we have
successfully reduced the number of project maintainers, for example in
devel:languages:perl we are down to 12 project maintainers.

The interface changes to hide the project maintainers for individual
packages have not been implemented, but there is a bug report #791088


> I am specially interested in
> those lists you mentioned.

I wrote a script to generate the lists and it mostly worked. The script
appears to trigger a bug, filed as 791103. I also sent the script to
Stephan for review and help, but obviously until 12.3 is out this will
have to wait.

I am hoping that after the release is done the bug preventing the script
from running will get fixed and we can move forward with this. Ideally I
will be able to give a lightning talk about this at oSC13 and show the
statistics and report on the progress.

Later,
Robert


--
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
[hidden email]
[hidden email]
781-464-8147
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer model clean up

Sascha Peilicke
Am 23.01.2013 16:06, schrieb Robert Schweikert:

> On 01/23/2013 09:45 AM, Cristian Morales Vega wrote:
>> On 26 October 2012 09:16, Robert Schweikert <[hidden email]> wrote:
>>> - We will collect information about all packages in all devel
>>> projects that
>>> feed factory. We will generate a list of packages that have no
>>> maintainer,
>>> and a list of packages that need help, i.e. a package that has fewer
>>> than 5
>>> maintainers. In addition we will list packages that have more than 5
>>> maintainers and try to encourage maintainers from those packages (to
>>> get the
>>> number to 5) to take on packages that need help.
>>
>> I guess during feature freeze it's not the best moment to start
>> playing with maintainership rights. But there is any progress about
>> all this "Maintainer model clean up"?
>
> Yes, there is progress. On a large number of projects we have
> successfully reduced the number of project maintainers, for example in
> devel:languages:perl we are down to 12 project maintainers.

Exactly. Besides the automated approach Rob is working on (below),
there's also a manual way to participate:

If a submit request to a particular project stalls for a longer period
of time it's sane to ask all the maintainers if they're still
interested. Everyone that does not reply looses his rights on the
project. Of course it can't hurt to ask here if anyone's interested to
take over.


>
> The interface changes to hide the project maintainers for individual
> packages have not been implemented, but there is a bug report #791088
>
>
>> I am specially interested in
>> those lists you mentioned.
>
> I wrote a script to generate the lists and it mostly worked. The script
> appears to trigger a bug, filed as 791103. I also sent the script to
> Stephan for review and help, but obviously until 12.3 is out this will
> have to wait.
>
> I am hoping that after the release is done the bug preventing the script
> from running will get fixed and we can move forward with this. Ideally I
> will be able to give a lightning talk about this at oSC13 and show the
> statistics and report on the progress.

Maybe it is worth mentioning that the overall goal is not to reduce the
number of maintainers or kick anyone out. To the contrary, we want to
have maintainers that active and caring and willing to advance the devel
projects (and thus Factory). Getting responses to your requests in time
(positive or negative) and a general vision for the devel project are
surely healthy ingredients to attract further contributions. Keeping the
number of build errors low and the number of packages increasing and
there versions current are too.
--
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend├Ârffer HRB 16746 (AG N├╝rnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]