|
 Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
* Bas Wijnen
| 5.11.1.2 Using the DELAYED/ queue
[...]
| The DELAYED queue should not be used to put additional pressure on the
| maintainer. In particular, it's important that you are available to
| cancel or delay the upload before the delay expires (the maintainer
| cannot cancel the upload himself).
Is there interest in changing this? Currently, each of the N-day/
directories are mode 1777, aka «tfheen and owner of file can remove
file». If there's interest in it, I'll be happy to make it so anybody
can remove anybody elses uploads.
Alternatively, I could have a script that understands dcut commands
and only acts if it's signed by the owner of the package (maintainer
or uploader).
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
Bas Wijnen wrote:
> Hi,
Hi
> === nmudiff improvements
Can you please just file a bug against devscripts and leave this out of
the DEP?
> = the nmudiff patch is not controversial. Why include it in the DEP?
>
> * If the DEP isn't agreed upon, the patch has no reason to be
> included in devscripts.
It also has no reason to not be included AFAICS.
> * It gives the opportunity to discuss the formulation at the same
> time as the rest of the DEP.
> * DEPs are supposed to allow changes in several parts of Debian at
> the same time. That's a good test case :-)
Ok, though I didn't see much discussion about it...
> = Is that really the best place to discuss stable, security and QA
> uploads, and binNMUs?
Yes, though the versioning of security uploads will probably be used and
decided by the Security Teams and the versioning of stable uploads will
probably be used and decided by the Stable Release Team anyway... Though
I won't oppose guidelines for the versioning.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Sun, May 25, 2008 at 11:05:14AM +0200, Tollef Fog Heen wrote:
> * Bas Wijnen
>
> | 5.11.1.2 Using the DELAYED/ queue
>
> [...]
>
> | The DELAYED queue should not be used to put additional pressure on the
> | maintainer. In particular, it's important that you are available to
> | cancel or delay the upload before the delay expires (the maintainer
> | cannot cancel the upload himself).
>
> Is there interest in changing this? Currently, each of the N-day/
> directories are mode 1777, aka «tfheen and owner of file can remove
> file». If there's interest in it, I'll be happy to make it so anybody
> can remove anybody elses uploads.
I think that would be better, indeed.
> Alternatively, I could have a script that understands dcut commands
> and only acts if it's signed by the owner of the package (maintainer
> or uploader).
Actually, anybody at all (DD only, that is) is better than "owner only"
IMO. When it's about NMUs, we're in a situation where external help is
more than a theoretical possibility. If some other external help wants
to fix a problem with an NMU which is still in the queue, this should be
possible IMO. Of course all parties (maintainer and previous NMUer)
should be informed, but that need not be automatic.
If this is changed, we should write a paragraph about how and when to do
this in the DEP as well.
Thanks,
Bas
Ps: This e-mail expresses my personal opinion, and is not written with
my "driver of this DEP" hat on. :-)
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
Hi Bas, and Lucas,
Le Sun, May 25, 2008 at 08:50:45AM +0200, Bas Wijnen a écrit :
>
> In some cases, the maintainer might allow direct commit to the package's
> VCS repository. We felt that it was not a good idea to include this in
> the DEP, because:
Actually, this leaves open the question whether the diff of the NMU
should be done against the current package in the Debian archive or the
work in progress in the maintainers VCS repository). One is clearer to
the users, and one is more useful for the maintainers. Which one do you
recommend?
Have a nice day,
--
Charles Plessy,
Wako, Saitama, Japan
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On 26/05/08 at 09:17 +0900, Charles Plessy wrote:
> Hi Bas, and Lucas,
>
> Le Sun, May 25, 2008 at 08:50:45AM +0200, Bas Wijnen a écrit :
> >
> > In some cases, the maintainer might allow direct commit to the package's
> > VCS repository. We felt that it was not a good idea to include this in
> > the DEP, because:
>
> Actually, this leaves open the question whether the diff of the NMU
> should be done against the current package in the Debian archive or the
> work in progress in the maintainers VCS repository). One is clearer to
> the users, and one is more useful for the maintainers. Which one do you
> recommend?
Let 1.0-1 be the version in the archive, 1.0-2 the version being
worked on in the VCS repository.
An NMUer is very likely to base his NMU on 1.0-1, because he will try to
do only the relevant changes to fix the bug he is interested in. In that
case, the only logical choice is to use 1.0-1 as the basis for the diff.
And it's actually more useful for the maintainer, don't you think so?
--
| Lucas Nussbaum
| lucas@... http://www.lucas-nussbaum.net/ |
| jabber: lucas@... GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
Le Mon, May 26, 2008 at 10:42:22AM +0200, Lucas Nussbaum a écrit :
> Let 1.0-1 be the version in the archive, 1.0-2 the version being
> worked on in the VCS repository.
>
> An NMUer is very likely to base his NMU on 1.0-1, because he will try to
> do only the relevant changes to fix the bug he is interested in. In that
> case, the only logical choice is to use 1.0-1 as the basis for the diff.
> And it's actually more useful for the maintainer, don't you think so?
It depends on how important are the VCS and package histories for the
maintainer and Debian. In order to acknowledge the NMU, it would be
necessary to revert the current work, apply the NMU patch, merge the
reverted work and resolve the conflicts. This is why the last time one
of my package had a NMU, I just ignored it instead of acknowledging it
(the upload I made would have closed the bug as well).
Have a nice day,
--
Charles Plessy
http://charles.plessy.orgWakō, Saitama, Japan
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
ma, 2008-05-26 kello 17:12 +0900, Charles Plessy kirjoitti:
> It depends on how important are the VCS and package histories for the
> maintainer and Debian. In order to acknowledge the NMU, it would be
> necessary to revert the current work, apply the NMU patch, merge the
> reverted work and resolve the conflicts. This is why the last time one
> of my package had a NMU, I just ignored it instead of acknowledging it
> (the upload I made would have closed the bug as well).
If the NMU is minimal, surely you should not have to undo all your own
changes, but just merge in the NMU.
(This is independent of whether things are done manually or with a
version control system.)
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On 25/05/2008, Bas Wijnen wrote:
> > Alternatively, I could have a script that understands dcut commands
> > and only acts if it's signed by the owner of the package (maintainer
> > or uploader).
>
> Actually, anybody at all (DD only, that is) is better than "owner
> only" IMO.
I beg to differ, there are many “owners” (as defined above) who are not
developers. Maybe allowing that for “owners” and all developers might do
the trick?
Mraw,
KiBi.
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On 26/05/2008, Charles Plessy wrote:
> It depends on how important are the VCS and package histories for the
> maintainer and Debian. In order to acknowledge the NMU, it would be
> necessary to revert the current work, apply the NMU patch, merge the
> reverted work and resolve the conflicts.
It looks to me like the wording of the 3rd paragraph of 5.11.2 is a bit
(too) strong: one must include the patch. It might be relaxed a bit so
that the maintainer is still allowed to implement the changes the way
s/he intends, rather than having to include the very patch sent to the
BTS.
> This is why the last time one of my package had a NMU, I just ignored
> it instead of acknowledging it (the upload I made would have closed
> the bug as well).
In which case, I'd probably dosomething like ACK'ing the NMU, adding a
“thanks to $nmuer, although the final implementation differs [details]”.
Mraw,
KiBi.
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Mon, May 26, 2008 at 05:12:23PM +0900, Charles Plessy wrote:
> It depends on how important are the VCS and package histories for the
> maintainer and Debian. In order to acknowledge the NMU, it would be
> necessary to revert the current work, apply the NMU patch, merge the
> reverted work and resolve the conflicts. This is why the last time one
> of my package had a NMU, I just ignored it instead of acknowledging it
> (the upload I made would have closed the bug as well).
As Lars said, if the NMU fix is minimal then it should be trivial to
just apply it directly to the VCS version (apart from the changelog
there should be a reasonable chance of patch being able to cope by
itself).
It's also important to consider why the changes that are in the VCS have
not been uploaded to the archive - it may be that it's simply a case of
nobody having got round to it yet but it could also be due to there
being some issues which need to be resolved.
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
Bas Wijnen wrote:
> 5.11.2 NMUs, from the maintainer's point of view
(...)
> When a package has been NMUed, the maintainer should acknowledge it in
> the next upload. This makes clear that the changes were accepted in the
> maintainer's packaging, and that they aren't lost again. For this, you
> must first incorporate the changes into your packaging, by applying the
> patch that was sent. Make sure to include the NMU's changelog entry in
> your own changelog. This is important to allow the BTS version tracking
> to work.
Could you clarify the above paragraph?
What do "changelog entry" mean?
- Is it a entire version entry, so the maintainer will simply add
a new debian version to the nmu changelog?
- or a changlelog line, so that the new changelog (from maintainer)
will not mention the nmu version, but only the nmu lines.
What about a new fix? Sometime maintainer does a real/clean
fix, instead of the work-around of nmu maintainer, considering
that the maintainer know better the structure of the program.
In this case, what should a maintainer do, without seeming
rude against nmu?
An other small comment, last part of
"5.11.1.1 NMUs and debian/changelog":
you write twice "security", but IMHO the security scheme
should be handled outside NMU (and in principle could
be done by the real maintainer). And there are also some
non-security updates in stable, so I prefer that you remove
the word security on the examples.
BTW I like the DEP1, and way it is written.
ciao
cate
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Mon, 26 May 2008, Mark Brown wrote:
> On Mon, May 26, 2008 at 05:12:23PM +0900, Charles Plessy wrote:
> As Lars said, if the NMU fix is minimal then it should be trivial to
> just apply it directly to the VCS version (apart from the changelog
> there should be a reasonable chance of patch being able to cope by
> itself).
When you base anything on an unreleased version, you have a lot more
potential to introduce issues. If you fix the current package with an
NMU, you have a known set of issues to deal with.
So, unless you *REALLY* know what you're doing, I'd say it is damn best
to stay the hell alway from anything in the VCS that has not been
uploaded yet in an NMU.
> It's also important to consider why the changes that are in the VCS have
> not been uploaded to the archive - it may be that it's simply a case of
> nobody having got round to it yet but it could also be due to there
> being some issues which need to be resolved.
Exactly. So, just don't do it as a *rule*, and leave the "upload from
VCS" as the exception.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Mon, 26 May 2008, Giacomo A. Catenazzi wrote:
> Bas Wijnen wrote:
>> 5.11.2 NMUs, from the maintainer's point of view
> (...)
>> When a package has been NMUed, the maintainer should acknowledge it in
>> the next upload. This makes clear that the changes were accepted in the
>> maintainer's packaging, and that they aren't lost again. For this, you
>> must first incorporate the changes into your packaging, by applying the
>> patch that was sent. Make sure to include the NMU's changelog entry in
>> your own changelog. This is important to allow the BTS version tracking
>> to work.
NMUs can be accepted *partially*. This means you merge the NMU, add the
entire changelog (if something has been uploaded to the archive, it is
to STAY in the changelog), then in the changelog entry for the new
version, you clearly specify which parts of the NMU where ACKed, and
which parts of it were rejected. And you revert the changes you
rejected, of course.
If the DEP1 has to hand-hold the DDs on how not to botch an NMU ACK, it
better be complete IMHO.
> What do "changelog entry" mean?
> - Is it a entire version entry, so the maintainer will simply add
> a new debian version to the nmu changelog?
> - or a changlelog line, so that the new changelog (from maintainer)
> will not mention the nmu version, but only the nmu lines.
The rule for changelogs is: avoid information loss. So, it is the first
one.
> What about a new fix? Sometime maintainer does a real/clean
> fix, instead of the work-around of nmu maintainer, considering
> that the maintainer know better the structure of the program.
> In this case, what should a maintainer do, without seeming
> rude against nmu?
You don't assume we're all a bunch of emotional wrecks without a life
who would make a fuss about it, and write something sensible for those
who will WORK on the package later on (that's what the changelog is
about), like "Rewrite fix for #2310410" or somesuch. Do we really have
to get to this kind of detail? I sure hope not...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
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).
Now, B reverts the entire NMU, and tell me to NEVER NMU ANY OF HIS
PACKAGES AGAIN. Or he acks it, cleans up whatever mess I made on the
side, and still tells me the same (to never touch his packages again).
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. Instead, I will have to be happy with just
sending patches to the BTS. If he just ignores them and doesn't fix the
bugs on his own, THEN I will have grounds to make a fuss, and get some
peer pressure to stop with any fief-lord delusions.
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.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
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.
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.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Mon, 26 May 2008 15:17:03 +0200, Raphael Hertzog < hertzog@...> 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.
I do not think that the NMU'er is the maintainer, and is
responsible for new upstream, long standing bugs, or the other things
the maintainer does. However, I think it is also unsustainable to give
the impression that drive by NMU's are just fine, and it is OK to leave
a train of wrecked packages in your wake.
This comes back to the principle that one is responsible for
what one uploads into the archive; if one's upload causes bugs, one is
responsible for taking care of the bugs.
manoj
--
Dammit Jim, I'm an actor, not a doctor.
Manoj Srivastava < srivasta@...> < http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...
|
|
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
by Manoj Srivastava
::
Rate this Message:
![]()
![]() |
signature.asc (196 bytes)