Hi Bas, and Lucas,

Le Sun, May 25, 2008 at 08:50:45AM +0200, Bas Wijnen a écrit :

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

On 26/05/08 at 09:17 +0900, Charles Plessy wrote:

Let 1.0-1 be the version in the archive, 1.0-2 the version being
worked on in the VCS repository.

Le Mon, May 26, 2008 at 10:42:22AM +0200, Lucas Nussbaum a écrit :

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.org
Wakō, Saitama, Japan

ma, 2008-05-26 kello 17:12 +0900, Charles Plessy kirjoitti:

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.)

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).

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.

On Mon, 26 May 2008, Mark Brown wrote:

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.

Exactly. So, just don't do it as a *rule*, and leave the "upload from
VCS" as the exception.

On 26/05/2008, Charles Plessy wrote:

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.

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

On Mon, May 26, 2008 at 11:56:12AM +0200, Cyril Brulebois wrote:

The proposal is to use the DELAYED queue as the default way to do an
NMU. This means in particular that the code is already finished when
the mail about the NMU is sent to the BTS. So there is no reason to
allow changes to the patch after this mail; if you need them, cancel the
NMU and upload an other one instead (sending the new patch to the BTS).

On 27/05/2008, Bas Wijnen wrote:

I'm talking about ACK'ing a previously-uploaded-and-accepted NMU in a
future upload.

Quoting Charles: “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.”

On Tue, May 27, 2008 at 08:01:27PM +0200, Cyril Brulebois wrote:

Oh, sorry, I didn't look up your reference and thought you were talking
about including the patch in the BTS.