|
|
 Up |
|
|
  |
Author: Henrique de Moraes HolschuhHenrique de Moraes Holschuh Date: May 26, 2008 06:00
On Sun, 25 May 2008, Bas Wijnen wrote:
> 3. NMUs are often received with angry comments from maintainers.
[...]
> This Debian Enhancement Proposal has two goals:
> 3. We try to encourage a responsible approach for NMUs,
> instead of an approach based on strict rules
[...]
I miss one thing in these guidelines: they sort of give you the idea you
can NMU someone's packages off as long as you go by the book, and that
you have the RIGHT to do it no matter what.
This is not strictly true, AFAIK only the release and security teams
have the right to NMU over and above everything else but the tech
comitee.
Suppose I NMU package A from maintainer B. Suppose I do a subpar job
from B's point of view (not that I will ever acknowledge it, I don't
even know it is supbar, it is as good as my own packages, it is not
subpar to ME. But I didn't do it as well as B would want it to be
done).
|
| Show full article (2.34Kb) |
|
| | 46 Comments |
|
|
Author: Raphael HertzogRaphael Hertzog Date: May 26, 2008 06:20
On Mon, 26 May 2008, Henrique de Moraes Holschuh wrote:
> Well, I *do* think in this situation, I am NOT to EVER NMU any of that
> maintainer's packages again, unless I go through one of the formal
> processes to override him.
This is an individual decision and doesn't need to be codified in any way.
(in particular when the situation described involves so many "if")
> If you need an example, we've had NMUs breaking essential packages. And
> I *think* we have had far more than an acceptable number of "fire and
> forget" NMUs happening too (but I don't have the hard data to back it
> up).
> Once you NMU, you are that package's daddy for *ALL* bugs that could
> even remotely be related to your NMU, until its maintainer shows
> up again... People who can't deal with that, must not NMU. Send the
> patch to the BTS instead.
This is not sustainable on the archive as a whole.
|
| Show full article (1.46Kb) |
|
| | no comments |
|
|
Author: Manoj SrivastavaManoj Srivastava Date: May 26, 2008 09:30
On Mon, 26 May 2008 15:17:03 +0200, Raphael Hertzog debian.org> said:
> On Mon, 26 May 2008, Henrique de Moraes Holschuh wrote:
>> Once you NMU, you are that package's daddy for *ALL* bugs that could
>> even remotely be related to your NMU, until its maintainer shows up
>> again... People who can't deal with that, must not NMU. Send the
>> patch to the BTS instead.
> This is not sustainable on the archive as a whole.
Could you elaborate? It certainly has been my understanding
that if you NMU a package, you are responsible for any breakage you
cause .
> It's always best top have an active developer for the most important
> packages so that DD who are not familiar with the code don't have to
> NMU at all... but in general, there's no need to go to that extreme
> route of saying that once NMUed you're the maintainer until the
> maintainer comes back.
|
| Show full article (1.75Kb) |
| no comments |
|
|
Author: Raphael HertzogRaphael Hertzog Date: May 27, 2008 00:00
On Mon, 26 May 2008, Manoj Srivastava wrote:
>> This is not sustainable on the archive as a whole.
>
> Could you elaborate? It certainly has been my understanding
> that if you NMU a package, you are responsible for any breakage you
> cause .
Check how we handled the switch to gcc4.3, a few people NMUed dozens of
package each and while they assume responsibility for breakage that they
cause they certainly didn't follow those packages in details after their
NMU.
They probably looked after FTFBS or other RC bugs because they appear
on their QA page ( http://qa.debian.org/developer.php?login= ) but
they probably didn't subscribe to the PTS of those packages and didn't
handle bug reports as if they were the maintainer.
And until we have only active maintainers, it's not reasonable to
be more demanding than that. I keep an eye on RC bugs in packages that I
NMUed, but that's about it.
|
| Show full article (1.80Kb) |
| no comments |
|
|
Author: Mark BrownMark Brown Date: May 27, 2008 05:00
On Tue, May 27, 2008 at 08:58:50AM +0200, Raphael Hertzog wrote:
> On Mon, 26 May 2008, Manoj Srivastava wrote:
>> Could you elaborate? It certainly has been my understanding
>> that if you NMU a package, you are responsible for any breakage you
>> cause .
> Check how we handled the switch to gcc4.3, a few people NMUed dozens of
> package each and while they assume responsibility for breakage that they
> cause they certainly didn't follow those packages in details after their
> NMU.
> They probably looked after FTFBS or other RC bugs because they appear
> on their QA page ( http://qa.debian.org/developer.php?login= ) but
> they probably didn't subscribe to the PTS of those packages and didn't
> handle bug reports as if they were the maintainer.
I don't see any substantial difference here - I don't think people are
suggesting that doing an NMU means you have to take on all the
responsibilities of maintainer but keeping an eye on the package for
breakage is reasonable and to a good approximation tracking RC bugs
should be adequate. I'd certainly expect anyone doing NMUs to do at
least that, though I tend to do this by subscribing to the PTS.
|
| Show full article (1.40Kb) |
| no comments |
|
|
Author: Lucas NussbaumLucas Nussbaum Date: May 29, 2008 12:50
On 26/05/08 at 09:55 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 25 May 2008, Bas Wijnen wrote:
>> 3. NMUs are often received with angry comments from maintainers.
>
> [...]
>
>> This Debian Enhancement Proposal has two goals:
>> 3. We try to encourage a responsible approach for NMUs,
>> instead of an approach based on strict rules
>
> [...]
>
> I miss one thing in these guidelines: they sort of give you the idea you
> can NMU someone's packages off as long as you go by the book, and that
> you have the RIGHT to do it no matter what.
I made the following change to the DEP to address this: (wdiff format)
When doing an NMU, you must always send a patch with the differences
between the current package and your NMU to the BTS. If the bug you
are fixing isn't reported yet, you must do that as well.
|
| Show full article (1.55Kb) |
| 3 Comments |
|
|
Author: Richard HeckerRichard Hecker Date: May 29, 2008 18:20
Lucas Nussbaum wrote:
> On 26/05/08 at 09:55 -0300, Henrique de Moraes Holschuh wrote:
>
......
>>
>> I miss one thing in these guidelines: they sort of give you the idea you
>> can NMU someone's packages off as long as you go by the book, and that
>> you have the RIGHT to do it no matter...
|
| Show full article (2.08Kb) |
| 2 Comments |
|
|
Author: Lucas NussbaumLucas Nussbaum Date: May 29, 2008 23:30
On 29/05/08 at 17:47 -0700, Richard Hecker wrote:
> Lucas Nussbaum wrote:
>> On 26/05/08 at 09:55 -0300, Henrique de Moraes Holschuh wrote:
>>> I miss one thing in these guidelines: they sort of give you the idea you
>>> can NMU someone's packages off as long as you go by the book, and that
>>> you have the RIGHT to do it no matter what.
>>>
>>
>> I made the following change to the DEP to address this: (wdiff format)
>>
>> When doing an NMU, you must always send a patch with the differences
>> between the current package and your NMU to the BTS. If the bug you
>> are fixing isn't reported yet, you must do that as well.
>>
>> {+After you upload an NMU, you are responsible for the possible
>> problems that you might have introduced. You must monitor the package
>> for a few weeks (subscribing to the package on the PTS is a good
>> idea).+}
>>
>> While there are no general rules, it's recommended to upload to the ...
|
| Show full article (3.12Kb) |
| 1 Comment |
|
|
Author: Bas WijnenBas Wijnen Date: May 30, 2008 00:50
On Thu, May 29, 2008 at 05:47:45PM -0700, Richard Hecker wrote:
> I see the same weakness that Henrique listed above. Some people will
> prepare a NMU without even sending an email to the maintainer.
Posting the patch in the BTS does actually send mail to the maintainer.
And it's nicely "in time", because with the DELAYED queue, the upload to
ftp-master doesn't happen before some days.
DELAYED is just a way to automate the "wait a while, then upload to
ftp-master" part. This DEP makes this explicit. A bug in the BTS is a
good way to contact a maintainter IMO. Using the DELAYED queue has an
added benefit that it is completely clear that an NMU will be done, and
when.
> I still want to stress that we should strive to improve communication
> when we can.
|
| Show full article (2.36Kb) |
| 5 Comments |
|
|
|
|
|
Author: Charles PlessyCharles Plessy Date: May 30, 2008 01:40
Le Fri, May 30, 2008 at 09:45:57AM +0200, Bas Wijnen a écrit :
>
> Yes, communication is good. We have several media for it, the two most
> important ones being mailing lists and the BTS (IMO). This DEP proposes
> to use the BTS for communication about NMUs. It was that way already
> AFAIK, although some people seem to think private mail was needed as
> well. To avoid any confusion, we should make it explicit in any case.
> If many people think private mail is needed before uploading to DELAYED,
> please speak up and we'll require that. To me, that would pretty much
> disable all usability of DELAYED, but that may be just me...
Hi Bas, Richard, Lucas,
the DEP says:
- must use BTS,
- usage of DELAYED is recommended.
|
| Show full article (1.46Kb) |
| no comments |
|
|
|
|
