Kevin F. Quinn wrote: >> It would but having some kind of deadline after which you are for >> example free to take over the package if you want to would be nice. > > That's going too far; there's certainly no need to take over a package > just to get a fix in. If you want to take over a package, asking the > current maintainer has to be the first step, not to quietly wait for a > timeout then just grab it. Similarly asking the current maintainer if > they mind you putting a fix in.
That's of course a given. I think the question here relates to
non-responsive maintainers or herds. I have been in the situation many
many times with gcc-porting where I file a bug with a simple patch (say
removing extra qualification) to get a package to build with GCC 4.1,
and get no response for months from the maintainer despite multiple
pings. In that case, i'll apply the fix myself. I always try to wait a
month or more before going ahead and always ping at least once. So far
i've not received any major complaints, but i'm just waiting for the day
someone will get territorial about their packages and decide rip me a
new one. It'd be nice to have some kind of asshole insurance.
This also affects things like treecleaners. How long does a herd team
or maintainer have to be unresponsive to warrant the package falling
into maintainer-needed? Right now the most common way we find these
packages is when Jakub gets annoyed enough with the accumulating bugs
and lack of response to CC us. ;P
I personally think that for bug fixes a month is a long enough wait to
allow someone to respond. Keep in mind that's to respond, not to fix
the bug. A simple "yep, i'll get to this later" is enough.
--
by design, by neglect
dirtyepic gentoo org for a fact or just for effect
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
signature.asc
Description: OpenPGP digital signature
