Re: Ideas about allowing Co-maintainer
Gustavo Noronha Silva <kov@debian.org> writes:
> Em Thu, 14 Aug 2003 16:42:20 +0200, Gaudenz Steinlin <gaudenz@soziologie.ch> escreveu:
>
> > If an obviously good an correct patch does not get applied, why not
> > prepare an updated package yourself an ask for a sponsor for an NMU,
> > explaining all the reasons for this uncommon action. I hope you will
> > find someone willing to do the upload if there are good reasons. Did
> > someone ever try this? I did not see any such request on debian-mentors.
>
> Not a good thing, sometimes... for instance, I have a patch for an
> important bug filled for sylpheed-claws. I know upstream is working
> on this issue, but it is far from trivial, and I am not willing to
> maintain a patch that causes too much discrepancy with upstream's
> version.
Then you can say so in the BTS and if someone realy minds he can fork
the package knowing that the changes would never get into your
package. Its the hanging in limo thats bad.
> Also, testing has its rules, and maintainer's policies on allowing
> packages to enter testing, etc should be respected... so I believe
> this is not that good in some cases.
Testing has a 10 day wait plus dependencies. We are talking about bugs
going back 1 to 5 years. For patches send in before potato was
released testing is realy no argument.
> I also believe that we need stricter rules on how to get packages
> going, anyway, because we must have a release, and we want to have
> the packages we love in it. So, I'd suggest that trivial stuff
> or RC bugs should be taken care of through NMU's if, after a one
> week delay the maintainer does not respond with a justification
> of why he's not uploading.
>
> Normal and important bugs, especially on upstream stuff should really
> have a special treatment, and more strict rules, and NMUs should
> really be done only by people closely following the packaging work.
Neigther the severity of the bug nor the triviality of the bug should
affect when an NMU can be done (but should affect when it will be
done, see below too). In my opinion the maintainer looses all rights
to controll his package if he is unresponsive for a long time. And I'm
not talking about a 1 month sabatical here but years.
On the other hand, if the maintainer responds regularly (to that bug),
even a 10 year old bug wouldn't warant an NMU. Like a NM changing and
refining a patch or idea and getting comments back from the maintainer
why its bad or wouldn't allways work.
I don't see a reason to not allow a simple correction in the docs
clarifying something (wishlist bug) to be NMUed just because its not
RC bug.
Another thing is that its hard enough to actually fix a complex bug
and then find a sponsor to NMU it. It shouldn't be made any harder.
DDs should be responsible enough to not just do major changes to a
package without due cause. The best example is gqview where the
question is how to handle the users wishes to have the unstable
version against the maintainers wish for the stable version. Noone is
just NMUing the major change but its thought out and discussed.
MfG
Goswin
Reply to: