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