On 8/13/13 8:39 AM, Alexis Ballier wrote: > Your arguments make sense but you should also consider it the other > way: When you are maintaining a package properly by forwarding patches > upstream, having $randomdev jumping in, adding a patch, and letting you > clean up the mess is kind of annoying. > > Part of Tomas' original email was: I've googled it for you, now would > you please submit that patch upstream and be forgiven?
I agree with staying very close to upstream and submitting patches to them. This is especially important for big packages like libreoffice or say chromium (I help to maintain the latter). Note that there is a possible confusion what ~arch is about. Are breakages allowed there? How long before they get fixed? For example, one could arguably say neon-0.30.0 was added to the tree without testing reverse dependencies. Interestingly, it was submitted by Arfrever (just stating the fact). To his defense, he submitted the libreoffice patch to bugzilla on the same day. Still, one could ask: why wasn't neon-0.30.0 masked instead? One thing I think is really important is respecting the maintainers. If maintainer said "please send the patch upstream before committing to cvs", it is _not_ OK to just ignore that. There are other options available like masking neon. And finally to the defense of libreoffice maintainers: packages take long time to compile, people have life. The policy about staying close to upstream is a very good one, and I can totally understand and agree with what they're saying. Paweł
signature.asc
Description: OpenPGP digital signature
