On 01/14/2012 12:10 PM, Iain Arnell wrote:
Then you can't blindly work the averages and apply hard limits. Just
because some packages are high maintenance, doesn't mean that can't
cope with dozens of low maintenance packages.
That hard limit is based on an guestimated time it takes to fix a single
bug from a guestimated free time an individual has to do so.
As you mentioned that it took you around 30 minutes to fix one bug on
average and I know for a fact that it takes me on average around 30
minutes to migrate legacy sysv init which is where that number initially
comes from since the steps are similar in that regard as in.
1 .I first have to look at the component in question in koji to see if
it is already shipping a unit file due to package maintainers not always
dropping the legacy sysv init script or package it in a separate sub
package as is stated by the guidelines.
2. I then have to look at all the bug reports filed against a component
to see if someone else has already migrated the legacy sysv init script
and submitted that.
3. if none of the above are true migrate the legacy sys init script and
perform minimal testing.
4. submit that to bugzillla and flag the component "inprogress" in
documentation
So 30 minutes is not that far off as an guestimated average.
Now 60(minutes)×4(guestimated available free hours)÷30( guestimated time
it takes to fix) = 8 which means you as an individual can cover fixing
bugs for 8 components per day which is the *worst case* scenario as in
each day all of the 8 components receive one bug report but in more
general terms I think it's safe to assume you can afford spending half
an hour on average per day per individual component if you maintain 8
components in general maintenance tasks for those components.
Soon as that number increases as in the time you have to spend in
maintaining 8 components you slowly start painting yourself into a
corner since you have to start taking the time from other activity's in
your daily route and of course as reality has it also works the other
way around your daily routine demands more of you thus you need start
cutting down you package maintainership.
People have tendency fooling themselves into they can handle it in the
long run until things have escalated way out of their control which
results from a package maintainership point of view things becomes more
sloppy and the user base is screaming at them ( they essentially are
working out issue because they have to not because they want to ) or
from the individual perspective people become more isolated, cut down on
general social activities, are at risk loosing their job and have their
wife and kids screaming at them since they aren't paying any attention
to them and we as a project loose them as a result of that.
What I'm trying to say here is that there is a magic number ( it might
be 8 it might be more but most likely it's less ) to how many packages
single individual can properly and reliably maintain in the distribution.
The rules become somewhat different with regards to the number of
components with "co-maintainership" but you still have only those
gestimated 4 hours to spend ( in reality this probably is a lower number ).
And ofcourse none of those things applies if you are unemployed, have no
social life, no girlfriend are living in your parents basement so in
theory you can maintain as many packages as you like without it
affecting you in anyway since you got all the time in the world...
Arguable for everyone's benefits, the projects and the projects users
and the maintainers and maintainers loved ones we should have a cab on
how many components maintainers are allowed to maintain from my pov.
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
