Collective maintenance

[Jesse Keating]

On Fri, Jun 13, 2008 at 4:17 PM, Jon Ciesla <limb at jcomserv.net> wrote:

>
> > Hi,
> >
> > A friend of mine pinged me and asked about the status of this bug
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=442921
> >
> > Just using this as an example here since it a simple one. This is
> > apparently just a simple missing dependency but hasn't been fixed in a
> > while. Just using this as a example, assuming that the maintainer is
> > busy, on vacation or something and cvsextras is open, many others could
> > fix this issue bypassing the primary maintainer for the moment but there
> > doesn't seem to be any policy on what kind of fixes can be collectively
> > done. I remember seeing similar discussions before so this isn't a
> > isolated problem. Do we need some guidelines on this so folks like
> > Michael Schwendt (again, just as an example specific to this bug report)
> > can just go ahead and fix the problem noting the details in the commit
> > message instead of having to file a bug report?
>
> My left brain side says, maybe we need a policy.  My right brain side
> says, if the acl is open, and you can fix it, fix it.
>
> Might actually check out doing that on some easy bugs I've reported.
>


It's a tough call, and really comes down to an issue by issue thing.  In
this issue there are a couple things going against it.

1) It's a bug regarding a released version, so any changes would require
bodhi updates

2) it's essentially enabling a feature, that may or may not work and one
would hope that if there was a reason this wasn't turned on, it would be
listed in the spec file.

For those reasons, I wouldn't be quick to jump in and try to fix it.  It'd
be worth doing a scratch build just to see if it would compile, and maybe
work but I still wouldn't feel comfortable without talking to the maintainer
in question first.

--
Jes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080613/70c2861e/attachment.htm>