frustrated newcomers AND orphaned packages (Was: Rebuild status of FE5)

[Jeff Spaleta]

On 2/27/06, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> - you open a bugzilla-ticket with a fix/enhancement. Maintainer does not
> react after N days (N=14, shorter timeframe if it's something more
> important, e.g. security or something is totally broken) -> you go ask
> on fedora-extras-list for comments and wait for another 24 hours ->
> apply patch and build

no for enhancements

2 weeks is too damn short for rfe's.. people have real lives that get
in the way... and I think policy needs to be aware of that. This is
the wrong solution.

The solution is pro-active team building no re-active patching. Are
you really going to demand that contributors respond to all
enhancement requests regardless of crackrock status? Sounds to me like
a great way to forcibly get a change into a package that the current
maintainer(s) doesn't support. Duplicate enhancement request for the
same thing over and over again until the maintainer decides not to
respond because its a waste of time to mark the dupes. I will not
personally support any policy which puts mandatory constraints on an
Extras contributor reply to bugzilla tickets for non-security feature
requests in X amount of time.

And I don't think letting people willy-nilly patch and build packages
is a good idea. If you want to set a time limit to strip
maintainership status of a package from someone and hand over
ownership status of the package to someone else.. fine. But
encouraging other contributors to blast through patch and build
updates for RFE's when they don't take over full responsibility is
asking for problems associated with updates.  Who's job is it to fix
problems associated with the new patched build? The original
maintainer? Or the person who put in the patch? The default policy on
patching and building should be, if you patch/build it..you own it,
unless you have the blessing of the current owner(s).  And this should
go for the security team as well. If we get a security team and they
have the authority to step in and patch/build something if the
maintainer is unavailable.. then the package should clearly change
ownership to the security team so its clear who is taking
responsibility for problems associated with that updated package...
until such time that the original maintainer is back in touch with the
project or the package.

>
> - if 'after N (N=something between 3 and 5) failed attempts to contact
> maintainer over N (N=something between 10 and 18) weeks' a package
> officially is orphaned.

No... i do not think allowing contributors to patch and build packages
they are not taking personal responsibility for is a good idea. All
this does is muddy the waters as to which group of people are going to
respond to problems resulting for that extraordinary patch/build and
whether or not the package is actually "orphaned".  Encouraging people
to hot patch something that is potentially orphaned makes it more
difficult to determine if its actually orphaned or not. I do not think
you can rely solely on open bugzilla ticket status as a reliable
measure as to orphan status because you are not going to get
consistent bugzilla usage across contributors. If you patch it in CVS
without the current owner's permission then you should be responsible
for it and that package should not be considered orphaned.

Instead of relying completely on ways to guess if a package is
orphaned.. I would prefer specific scheduled points in time when all
packagers/teams re-affirm their maintainership over packages and which
branches they are actively maintaining. The goal should be to
establish as much multi-contributor coverage over packages as
possible, before multi-contributor coverage is actually needed.  A
scheduled, reliable, re-affirm process will help us
identify..proactively..what packages are under multi-contributor team
oversight and which aren't and can help us tell the difference between
a packager that has left the ranch completely and someone who is afk
for a 2 week vacation.

-jef