Re: Proposal to update NMU section 5.11.1

2012-04-27 Thread Bernhard R. Link 
* Charles Plessy  [120426 02:08]:
> Thanks for the information, I thought it was obsoleted when the closing of 
> bugs
> became versionned.

Before closing become versioned, the situation was more complex:

 Before, a upload of a .changes would behave differently depending
 whether it was a NMU or not. If it was a MU then there were mails
 to -d...@bugs.debian.org sent (just as they are now) but if it
 was a NMU, then this was not done. Instead those bugs got the tag
 "fixed".
 Thus if you acknowledged an NMU with the following MU, you had
 again close all the bugs in the new changelog of the package (so they
 would now be properly closed).
 This was necessary to avoid bugs being closed in a NMU but that change
 being silently reverted by the maintainer uploading a new version
 ignoring the NMU.

 For example that looked like
| e2fsprogs (1.38-2) unstable; urgency=low
|
|   * Previous NMU acknowledged (Closes: #317862, #320389)
| [...]

Since bug-closing is versioned that is no longer necessary.
bugs.debian.org keeps the information about what version a bug was
closed in and has the information which version is based on which
version.

Thus if there is now a .changes uploaded, the bugs it closes are closed,
no matter if it is a MU or a NMU. And the bts keeps track if those bugs
are closed in the current version.

So a bug only marked to be closed in 1-1.1 will be consider open in 1-2
in the left case, but consider closed in 1-2 in the right case:

 1-2   1-2
  | |
  |  1-1.1 1-1.1
  | /   |
 1-1   1.1

To get the information, which package is based on which package, the
debian/changelog file is considered, so you need to have the NMU's
changelog there. (Or you need to close all those bugs again, like it was
done before versioned closes where introduced).

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120427090702.ga10...@client.brlink.eu

Re: Proposal to update NMU section 5.11.1

2012-04-25 Thread Russ Allbery 
Charles Plessy  writes:

> I am still confused.  Does the discussed paragraph mean that the whole
> NMU changelog entry has to be still present in the changelog, just under
> the latest entry, or that they have to be closed again in the latest
> entry ?

Either one will work for keeping the fixed versions accurate.  However,
they will have different representations in the graphs that you see in the
BTS in the upper right corner.

If you close the bugs in the current entry but don't include the NMU
changelog entries, the BTS will show your upload as a new version based
off of the last maintainer upload, and the NMU versions as a separate
branch unrelated to your new upload.

If you instead include the NMU changelog (I'm not sure if building with -v
of the last maintainer upload is also required, but it couldn't hurt),
your new version will instead be a descendent of the last NMU, and the
graph will remain a straight line.

The appearance of the graph really doesn't much matter except for
aesthetics and the corner case of new bugs with found versions in the past
and how those bugs are then inherited by later versions.  If all you care
about is ensuring the bug doesn't appear to be still open in some
interesting branch of the versions, either approach will work.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk9zcmah@windlord.stanford.edu

Re: Proposal to update NMU section 5.11.1

2012-04-25 Thread Charles Plessy 
Le Wed, Apr 25, 2012 at 05:38:11PM -0700, Don Armstrong a écrit :
> 
> Versioning is a directed acyclic graph. Each version has at most one
> ancestor, though it may have many descendants. When you upload a
> maintainer upload (MU) without including the NMU changelog entry, you
> are indicating that your version is a descendant of the previous MU,
> not the NMU. That's perfectly ok, but if you've actually fixed bugs
> that were fixed in the NMU in your MU, you need to include lines in
> the changelog to that effect, or later on manually fix-up the
> versions.

I am still confused.  Does the discussed paragraph mean that the whole NMU
changelog entry has to be still present in the changelog, just under the latest
entry, or that they have to be closed again in the latest entry ?

Perhaps the Developers Reference could more direct about how things work,
like:

In the BTS, the package versions are represented as a directed acyclic graph.
Make sure that your next upload following a NMU contains the NMU entry in the
package's changelog, or the upload will not be considered a descendant from the
NMU in the BTS's version graph, and therefore the bugs fixed in the NMU will
still be listed as affecting the package that you just uploaded and its
descendants.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120426011230.gd26...@falafel.plessy.net

Re: Proposal to update NMU section 5.11.1

2012-04-25 Thread Don Armstrong 
On Thu, 26 Apr 2012, Charles Plessy wrote:
> Le Wed, Apr 25, 2012 at 04:19:50PM -0700, Don Armstrong a écrit :
> > Yes, that's still how the BTS works. Otherwise, the MU is a
> > descendant of the previous MU instead of the NMU. You can
> > alternatively just include the changelog entries from the NMU too.
> > Either works.
> 
> Thanks for the information, I thought it was obsoleted when the
> closing of bugs became versioned.

It's a consequence of how versioning works.
 
> Can you describe somewhere what the BTS is doing on that matter ?  I do not
> understand the rationale and the function.

Versioning is a directed acyclic graph. Each version has at most one
ancestor, though it may have many descendants. When you upload a
maintainer upload (MU) without including the NMU changelog entry, you
are indicating that your version is a descendant of the previous MU,
not the NMU. That's perfectly ok, but if you've actually fixed bugs
that were fixed in the NMU in your MU, you need to include lines in
the changelog to that effect, or later on manually fix-up the
versions.

>  Also, I thought that changelog-driven interaction with the BTS was
> only carried through dpkg-genchanges and dak...

Yes, that's correct.

> Can missing acknowledgements be corrected via the email interface ?

No. [In the sense that you can't change the DAG after it has been sent
from dak to the BTS. You can fix up mistakes in the found/fixed
versions, though.]

> Are there other direct interactions between a package and the BTS
> with its changelog ?

The BTS only sees the snippets of the changelog that dak presents to
the BTS. [And then the e-mails that dak sends to nnn-close@bdo, but
those merely close the bug in a version and don't affect the DAG.]
 

Don Armstrong

-- 
Science is a way of trying not to fool yourself. The first principle
is that you must not fool yourself, and you are the easiest person to
fool.
 -- Richard Feynman "What is and What Should be the Role of Scientific
Culture in Modern Society"; 1964

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120426003811.gn3...@rzlab.ucr.edu

Re: Proposal to update NMU section 5.11.1

2012-04-25 Thread Charles Plessy 
Le Wed, Apr 25, 2012 at 04:19:50PM -0700, Don Armstrong a écrit :
> On Thu, 26 Apr 2012, gregor herrmann wrote:
> > On Wed, 25 Apr 2012 09:33:31 +0900, Charles Plessy wrote:
> > 
> > > Talking about improvements, if the following part about NMU 
> > > acknowledgement is
> > > obsolete as I think, how about removing it, either as a separate bug, or 
> > > as
> > > part of the general refresh of the section that is discussed here.
> > > 
> > >   To acknowledge an NMU, include its changes and changelog entry in your 
> > > next
> > >   maintainer upload. If you do not acknowledge the NMU by including the 
> > > NMU
> > >   changelog entry in your changelog, the bugs will remain closed in the 
> > > BTS but
> > >   will be listed as affecting your maintainer version of the package. 
> > 
> > Is this obsolete? In my understanding this is still how the BTS
> > works; but I might have missed any changes.
> 
> Yes, that's still how the BTS works. Otherwise, the MU is a descendant
> of the previous MU instead of the NMU. You can alternatively just
> include the changelog entries from the NMU too. Either works.

Thanks for the information, I thought it was obsoleted when the closing of bugs
became versionned.

Can you describe somewhere what the BTS is doing on that matter ?  I do not
understand the rationale and the function.  Also, I thought that
changelog-driven interaction with the BTS was only carried through
dpkg-genchanges and dak...  Can missing acknowledgements be corrected via the
email interface ?  Are there other direct interactions between a package and
the BTS with its changelog ?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120426000837.gb26...@falafel.plessy.net

Re: Proposal to update NMU section 5.11.1

2012-04-25 Thread Don Armstrong 
On Thu, 26 Apr 2012, gregor herrmann wrote:
> On Wed, 25 Apr 2012 09:33:31 +0900, Charles Plessy wrote:
> 
> > Talking about improvements, if the following part about NMU acknowledgement 
> > is
> > obsolete as I think, how about removing it, either as a separate bug, or as
> > part of the general refresh of the section that is discussed here.
> > 
> >   To acknowledge an NMU, include its changes and changelog entry in your 
> > next
> >   maintainer upload. If you do not acknowledge the NMU by including the NMU
> >   changelog entry in your changelog, the bugs will remain closed in the BTS 
> > but
> >   will be listed as affecting your maintainer version of the package. 
> 
> Is this obsolete? In my understanding this is still how the BTS
> works; but I might have missed any changes.

Yes, that's still how the BTS works. Otherwise, the MU is a descendant
of the previous MU instead of the NMU. You can alternatively just
include the changelog entries from the NMU too. Either works.


Don Armstrong

-- 
-tommorow is our permanent address
and there they'll scarcely find us(if they do,
we'll move away still further:into now
 -- e.e. cummings "XXXIX" _1 x 1_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120425231950.gm3...@rzlab.ucr.edu

Re: Proposal to update NMU section 5.11.1

2012-04-25 Thread gregor herrmann 
On Wed, 25 Apr 2012 09:33:31 +0900, Charles Plessy wrote:

> Talking about improvements, if the following part about NMU acknowledgement is
> obsolete as I think, how about removing it, either as a separate bug, or as
> part of the general refresh of the section that is discussed here.
> 
>   To acknowledge an NMU, include its changes and changelog entry in your next
>   maintainer upload. If you do not acknowledge the NMU by including the NMU
>   changelog entry in your changelog, the bugs will remain closed in the BTS 
> but
>   will be listed as affecting your maintainer version of the package. 

Is this obsolete? In my understanding this is still how the BTS
works; but I might have missed any changes.

Cheers,
gregor, cc'ing owner@
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital signature

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Charles Plessy 
Le Wed, Apr 25, 2012 at 02:01:48AM +0200, gregor herrmann a écrit :
> On Tue, 24 Apr 2012 12:34:00 -0400, Chris Knadle wrote:
> 
> > For instance, say a potential maintainer picks up an old package to do an 
> > NMU 
> > on, and updates the version of debhelper from v5 to v8, switches from 1.0 
> > format to 3.0 quilt format, and likewise has to make numerous other similar 
> > tweaks both to the debian files and patching the upstream source.  Are any 
> > of 
> > these possibly considered part of packaging style in terms of this section 
> > of 
> > the Dev Ref?
> 
> IMO: yes, to all of these examples.
> 
> As I understand it, NMUs should only do the minimal necessary changes
> needed to fix a bug (in order to make it easy for the maintainer to
> incorporate the diff).
> 
> Changing patch systems, debhelper/cdbs/dh, source format etc. would
> indeed be sometimes easier for the NMUer, but they are usually not
> _necessary_ for solving a problem. This might lead to more work when
> preparing an NMU but that's not the main priority.
> 
> (For totally outdated packages it might make more sense to think
> about getting them orphaned by the MIA team or discussing their
> removal.)
> 
> And this is only 1) my personal understanding of 2) the current
> situation; I might be wrong, and the common interpretation might
> change :)
>  
> 
> In general, I agree that zack's wording _sounds_ more positive towards
> NMUs than the language in DevRef at the moment, and I wouldn't mind
> if you came up with improvements.

Talking about improvements, if the following part about NMU acknowledgement is
obsolete as I think, how about removing it, either as a separate bug, or as
part of the general refresh of the section that is discussed here.

  To acknowledge an NMU, include its changes and changelog entry in your next
  maintainer upload. If you do not acknowledge the NMU by including the NMU
  changelog entry in your changelog, the bugs will remain closed in the BTS but
  will be listed as affecting your maintainer version of the package. 

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120425003331.ga8...@falafel.plessy.net

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread gregor herrmann 
On Tue, 24 Apr 2012 12:34:00 -0400, Chris Knadle wrote:

> For instance, say a potential maintainer picks up an old package to do an NMU 
> on, and updates the version of debhelper from v5 to v8, switches from 1.0 
> format to 3.0 quilt format, and likewise has to make numerous other similar 
> tweaks both to the debian files and patching the upstream source.  Are any of 
> these possibly considered part of packaging style in terms of this section of 
> the Dev Ref?

IMO: yes, to all of these examples.

As I understand it, NMUs should only do the minimal necessary changes
needed to fix a bug (in order to make it easy for the maintainer to
incorporate the diff).

Changing patch systems, debhelper/cdbs/dh, source format etc. would
indeed be sometimes easier for the NMUer, but they are usually not
_necessary_ for solving a problem. This might lead to more work when
preparing an NMU but that's not the main priority.

(For totally outdated packages it might make more sense to think
about getting them orphaned by the MIA team or discussing their
removal.)

And this is only 1) my personal understanding of 2) the current
situation; I might be wrong, and the common interpretation might
change :)
 

In general, I agree that zack's wording _sounds_ more positive towards
NMUs than the language in DevRef at the moment, and I wouldn't mind
if you came up with improvements.

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital signature

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Michael Gilbert 
On Tue, Apr 24, 2012 at 2:22 PM, Chris Knadle wrote:
> I already proposed to write a bug report against the developers-refernece
> package in the email prior to the one you're replying to. [1]
>
> [1] http://lists.debian.org/debian-policy/2012/04/msg00046.html

Then do it!

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mo0wkp9ctje-wghuogltvqn6gvrctbj7uf7q8tocys...@mail.gmail.com

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Chris Knadle 
Thanks for replying -- you had several informative points.  [And thanks for 
your work on the wine packages.]  I just need to correct the following:

On Tuesday, April 24, 2012 14:01:10, Michael Gilbert wrote:
> On Tue, Apr 24, 2012 at 12:45 PM, Chris Knadle wrote:
>> On Tuesday, April 24, 2012 03:19:11, Thijs Kinkhorst wrote:
...
> >> I do think Lucas is right - you are taking a rather large leap of
> >> interpretation: from very specific ("no cosmetic changes or switching
> >> packaging style") to rather generic ("nothing other than critical
> >> bugs"). There's a host of issues in between, they are not excluded in
> >> the text but they are excluded in what you say the text 'implies'. I
> >> would indeed suggest, like Lucas, not to try too hard to find
> >> 'implications' or 'between the lines' text, which isn't actually there.
> > 
> > As I mentioned in the my most recent reply, the overall tone of the
> > section overall is why interpret the wording of the section that way.
> 
> So, like I said, the NMU section can certainly be improved.  The best
> way to do that is to start a new bug report with a diff of the wording
> that you think should change.  Debian values work, rather than
> discussion, so please put in the work.

I already proposed to write a bug report against the developers-refernece 
package in the email prior to the one you're replying to. [1]

[1] http://lists.debian.org/debian-policy/2012/04/msg00046.html

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Michael Gilbert 
On Tue, Apr 24, 2012 at 12:45 PM, Chris Knadle wrote:
>> > Try to read between the lines -- it implies "be reluctant to do an NMU
>> > unless you're absolutely sure of what you're doing".  That's a much
>> > higher bar than the spirit that I think is embodied in Zack's email
>> > describing NMUs.
>>
>> This seems like valuable advice for any upload, including NMU's, so I
>> don't think this bar needs to be lowered at all, nor do I think Zack
>> promotes that.
>
> Somehow I interpret that differently.

Being careful with all changes in all uploads is important, but that
doesn't mean that taking risks is completely disallowed.  The person
doing that just needs to be ready to fix the problems he or she
created.

>> > And there's a difference between being correct and being informative.
>> > i.e. just because a statement is correct doesn't mean it conveys what DDs
>> > need to know.
>>
>> Is there a concrete problem with DD's misunderstanding this text?
>
> Is this an answerable question?  What would be required to be able to give a
> valid answer?
>
> I can point to emails of people misconstruing what NMUs are for, but that
> doesn't mean they've read the Dev-Ref section or even that they're DDs, and
> far harder to prove that it's a common "concrete" problem.

As a point of reference, as a (new) DD, I had also drawn the
conclusion that new upstream versions were likely disallowed in NMUs,
but I reached that from a different direction.

My understanding came from the fact that the NMU diff needed to be
included in the bug report to make it easy for the maintainer to adopt
the NMUer's changes.  For new upstream versions, the NMU diff is most
often huge and unwieldy, and largely unfriendly thing for the
maintainer, so I thought that made such an NMU wrong.

I am no longer of that mindset, as I now realize that VCS updates are
a user-friendly alternative to large diffs.  That is what we are now
doing for wine:
http://lists.alioth.debian.org/pipermail/pkg-wine-party/2012-April/001815.html

You may also want to read some of the other ongooings in wine for the
past month (and subscribe to the list):
http://lists.alioth.debian.org/pipermail/pkg-wine-party/2012-April/thread.html

So, the current wording of the developers reference doesn't preclude
this work. That isn't to say that it couldn't be further improved (it
could certainly use some wording about VCS work in cases where NMU
diffs are far too unwieldy), but it seems to be mostly working as is.

>> I do think Lucas is right - you are taking a rather large leap of
>> interpretation: from very specific ("no cosmetic changes or switching
>> packaging style") to rather generic ("nothing other than critical bugs").
>> There's a host of issues in between, they are not excluded in the text but
>> they are excluded in what you say the text 'implies'. I would indeed
>> suggest, like Lucas, not to try too hard to find 'implications' or
>> 'between the lines' text, which isn't actually there.
>
> As I mentioned in the my most recent reply, the overall tone of the section
> overall is why interpret the wording of the section that way.

So, like I said, the NMU section can certainly be improved.  The best
way to do that is to start a new bug report with a diff of the wording
that you think should change.  Debian values work, rather than
discussion, so please put in the work.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MNwQe54Gaz16S75u_TY5Dq6K1Uw=laafndz5c2o...@mail.gmail.com

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Guillem Jover 
On Tue, 2012-04-24 at 00:54:41 +0200, Lucas Nussbaum wrote:
> On 23/04/12 at 17:24 -0400, Chris Knadle wrote:
> > Section 5.11.1:
> > 
> > - Seems to imply that the only reason to do an NMU is for fixing bugs.  In 
> > interpreting this, it is not clear that a wishlist bug report of "please 
> > package the new upstream version" is something that could be valid to do an 
> > NMU for if the maintainer doesn't have time to do the work.
> 
> wishlist bugs are bugs, so they are covered.

While some wishlist requests can be clearly considered bugs, not all
of them are. The ones that are not, must get the same consideration
the style and cosmetic advice gives later on, because not doing so
inflicts the maintenance cost involved in carrying that delta around
onto the maintainer, the additional penalty of having to maintain this
further due to compatibility reasons if upstream does not accept that
code at all or in a different form, more so if the maintainer has for
example a 0-delta policy regarding upstream changes, etc.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120424170056.ga7...@gaara.hadrons.org

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Chris Knadle 
On Tuesday, April 24, 2012 03:19:11, Thijs Kinkhorst wrote:
> On Tue, April 24, 2012 08:50, Chris Knadle wrote:
> >> > - States that leaving an open grave bug might be better than possibly
> >> > uploading a version that breaks something else
> >> 
> >> that's correct
> > 
> > Try to read between the lines -- it implies "be reluctant to do an NMU
> > unless you're absolutely sure of what you're doing".  That's a much
> > higher bar than the spirit that I think is embodied in Zack's email
> > describing NMUs.
> 
> This seems like valuable advice for any upload, including NMU's, so I
> don't think this bar needs to be lowered at all, nor do I think Zack
> promotes that.

Somehow I interpret that differently.

> > And there's a difference between being correct and being informative.
> > i.e. just because a statement is correct doesn't mean it conveys what DDs
> > need to know.
> 
> Is there a concrete problem with DD's misunderstanding this text?

Is this an answerable question?  What would be required to be able to give a 
valid answer?

I can point to emails of people misconstruing what NMUs are for, but that 
doesn't mean they've read the Dev-Ref section or even that they're DDs, and 
far harder to prove that it's a common "concrete" problem.

> > > - Implies that the NMU package shouldn't make any changes other than
> >> 
> >> some
> >> 
> >> > time of critical bug fix -- quoting: "Fixing cosmetic issues or
> >> 
> >> changing
> >> 
> >> > the packaging style in NMUs is discouraged."
> >> 
> >> You are over-reading.
> > 
> > Saying this is not helpful.
> 
> I do think Lucas is right - you are taking a rather large leap of
> interpretation: from very specific ("no cosmetic changes or switching
> packaging style") to rather generic ("nothing other than critical bugs").
> There's a host of issues in between, they are not excluded in the text but
> they are excluded in what you say the text 'implies'. I would indeed
> suggest, like Lucas, not to try too hard to find 'implications' or
> 'between the lines' text, which isn't actually there.

As I mentioned in the my most recent reply, the overall tone of the section 
overall is why interpret the wording of the section that way.


  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Chris Knadle 
On Tuesday, April 24, 2012 03:46:59, Lucas Nussbaum wrote:
> Hi,
> 
> Adding zack to Cc.

Cool.

> Note that this discussion should really take place in a public place.
> Maybe in a bug report?

Huh... I was going to ask where to do that, but I just realized the existence 
of the 'developers-reference' package, so I could file a wishlist bug in the 
BTS for the package.  Yeah I think that's a good idea.

> On 24/04/12 at 02:50 -0400, Chris Knadle wrote:
> > On Monday, April 23, 2012 18:54:41, Lucas Nussbaum wrote:
> > > On 23/04/12 at 17:24 -0400, Chris Knadle wrote:
...
> > > > Not exactly, no -- the reason is that section 5.11.1 doesn't state
> > > > what isn't allowed with NMUs, and instead seems worded on the
> > > > conservative side and simply makes recommendations of when NMUs
> > > > might be appropriate or not.  In other words, I think the section is
> > > > a little too vague, and simultaneously doesn't seem to correspond
> > > > with what Zack believes can be done with NMUs.
> > > > 
> > > > Section 5.11.1:
> > > > 
> > > > - Seems to imply that the only reason to do an NMU is for fixing
> > > > bugs. In interpreting this, it is not clear that a wishlist bug
> > > > report of "please package the new upstream version" is something
> > > > that could be valid to do an NMU for if the maintainer doesn't have
> > > > time to do the work.
> > > 
> > > wishlist bugs are bugs, so they are covered.
> > 
> > I now that *now*, but only because of discussion on [debian-devel], and
> > not because of Section 5.11 of the Developer's Reference.  :-(
> > 
> > Let me state the issue another way -- when it comes to NMUs, my personal
> > reference on them is now Zack's email, and not the Developer's Reference.
> >  :-/ I want others to be able to get at least the same level of
> > understanding of NMUs that I currently have now after discussing it on
> > [debian-devel], without having the DPL needing to repeatedly explain
> > them.
> 
> I don't think that what the DPL stated in that thread is fundamentally
> different from what is described in dev-ref. Also, note that the DPL was
> expressing his opinion, and that, because the DPL expresses an opinion,
> it does not necessarily become the opinion of the project.

:-/  I'm *not* at all trying to say "the DPL is the authority".  I'm saying 
that what Zack wrote about NMUs makes a lot more logical sense to me than 
what's in section of 5.11.1 of the Dev Ref right now.

> > > > - States that leaving an open grave bug might be better than possibly
> > > > uploading a version that breaks something else
> > > 
> > > that's correct
> > 
> > Try to read between the lines -- it implies "be reluctant to do an NMU
> > unless you're absolutely sure of what you're doing".  That's a much
> > higher bar than the spirit that I think is embodied in Zack's email
> > describing NMUs.
> > 
> > And there's a difference between being correct and being informative. 
> > i.e. just because a statement is correct doesn't mean it conveys what
> > DDs need to know.
> > 
> > > > - Implies that the NMU package shouldn't make any changes other than
> > > > some time of critical bug fix -- quoting: "Fixing cosmetic issues or
> > > > changing the packaging style in NMUs is discouraged."
> > > 
> > > You are over-reading.
> > 
> > Saying this is not helpful.
> 
> Seriously, if the dev-ref states:
> > Fixing cosmetic issues or changing the packaging style in NMUs is
> > discouraged.
> 
> And you understand:
> > the NMU package shouldn't make any changes other than some time of
> > critical bug fix
> 
> I don't know how I can help you.

Short single sentence replies of "you are " is geek speak for "I'm not 
interested in what you're saying", so I was trying to get you to consider how 
you were communicating.

I've tried to explain the disparity between the impression I get from Section 
5.11.1 verses the impression I get from Zack concerning NMUs, and I'm saying 
the two impressions don't match in ways I think are significant.  I think you 
might be misunderstanding that the OVERALL TONE of the entire section is part 
of the issue.  Anywhere statements are vague, the tone can alter the meaning.  
I listed the sentence as an example of the tone.  Nitpicking my interpretation 
of the one sentence alone misses the point.

> Fixing minor bugs or wishlist bugs in an NMU are OK. Basically, what
> should not be done in the general case is making decisions, opposite to
> the maintainer's own choices, that are mainly a matter of taste.
> For exammple, switching from cdbs to dh (without the maintainer's
> approval).

The above makes complete sense, but that's not what the section of the Dev-Ref 
says; it simply says "changing packaging style is discouraged", but not what 
"packaging style" means.

For instance, say a potential maintainer picks up an old package to do an NMU 
on, and updates the version of debhelper from v5 to v8, switches from 1.0 
format to 3.0 quilt format, and likewise has to make numerous

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Antti-Juhani Kaijanaho 
On Tue, Apr 24, 2012 at 09:46:59AM +0200, Lucas Nussbaum wrote:
> Note that this discussion should really take place in a public place.

It looks to me it's already in a public place.  I for one am receiving this
through the debian-policy mailing list.

> Maybe in a bug report?

But that sounds like a good idea.

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120424090311.ga5...@kukkaseppele.kaijanaho.fi

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Stefano Zacchiroli 
On Tue, Apr 24, 2012 at 09:46:59AM +0200, Lucas Nussbaum wrote:
> Note that this discussion should really take place in a public place.
> Maybe in a bug report?

Yes, definitely.

> I don't think that what the DPL stated in that thread is fundamentally
> different from what is described in dev-ref. Also, note that the DPL was
> expressing his opinion, and that, because the DPL expresses an opinion,
> it does not necessarily become the opinion of the project.

ACK, on both fronts (I think what I meant is already in the devref,
maybe it should just be worded differently; and that was my personal
opinion: I think the dev-ref maints have the final say here, possibly
after having consulted people more broadly as they did with DEP-1).

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120424085829.ga8...@upsilon.cc

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Lucas Nussbaum 
Hi,

Adding zack to Cc.

Note that this discussion should really take place in a public place.
Maybe in a bug report?

On 24/04/12 at 02:50 -0400, Chris Knadle wrote:
> On Monday, April 23, 2012 18:54:41, Lucas Nussbaum wrote:
> > On 23/04/12 at 17:24 -0400, Chris Knadle wrote:
> > > Oops... sending again, as I forgot to CC: the developer's reference team.
> > > 
> > > On Monday, April 23, 2012 16:26:59, Lucas Nussbaum wrote:
> > > > Hi,
> > > > 
> > > > On 23/04/12 at 14:56 -0400, Chris Knadle wrote:
> > > > > Greetings.
> > > > > 
> > > > > I would like your consideration as to whether to update Section
> > > > > 5.11.1 of the Developer's Reference to incorporate some of the views
> > > > > of Stefano Zacchiroli concerning "When and how to do an NMU".  [1]
> > > > > 
> > > > > For background as to why this came up, there's recently been
> > > > > discussion about several packages in Debian that are quite out of
> > > > > date compared to upstream, including the WINE packages -- this
> > > > > thread starts at [2].  If you browse the 'wine' source package at
> > > > > [3], you can see what has transpired: there used to be several
> > > > > people collaborating on the wine packages, but for whatever reason
> > > > > it ended up being left to only one maintainer doing the work.  This
> > > > > maintainer has stated [4] that he has time overloaded elsewhere so
> > > > > that he doesn't have time to work on the packages now, but
> > > > > simultaneously has QA requirements such that all of the older
> > > > > pre-1.2 wine versions must be packaged first before packaging
> > > > > versions 1.2 and 1.4.
> > > > > 
> > > > > It seems like NMU(s) on the package(s) would be a reasonable course
> > > > > of action, but the current wording of Section 5.11.1 in the
> > > > > Developer's Reference [5] would seem to discourage this -- or at
> > > > > least that's how I personally interpret the current wording.  This
> > > > > is the reason I would like to revisit this issue to see whether
> > > > > updating the wording in this section would be appropriate.
> > > > 
> > > > Could you be a bit more specific about what you believe is not allowed
> > > > to do using NMUs?
> > > 
> > > Not exactly, no -- the reason is that section 5.11.1 doesn't state what
> > > isn't allowed with NMUs, and instead seems worded on the conservative
> > > side and simply makes recommendations of when NMUs might be appropriate
> > > or not.  In other words, I think the section is a little too vague, and
> > > simultaneously doesn't seem to correspond with what Zack believes can be
> > > done with NMUs.
> > > 
> > > Section 5.11.1:
> > > 
> > > - Seems to imply that the only reason to do an NMU is for fixing bugs. 
> > > In interpreting this, it is not clear that a wishlist bug report of
> > > "please package the new upstream version" is something that could be
> > > valid to do an NMU for if the maintainer doesn't have time to do the
> > > work.
> > 
> > wishlist bugs are bugs, so they are covered.
> 
> I now that *now*, but only because of discussion on [debian-devel], and not 
> because of Section 5.11 of the Developer's Reference.  :-(
> 
> Let me state the issue another way -- when it comes to NMUs, my personal 
> reference on them is now Zack's email, and not the Developer's Reference.  
> :-/  
> I want others to be able to get at least the same level of understanding of 
> NMUs that I currently have now after discussing it on [debian-devel], without 
> having the DPL needing to repeatedly explain them.

I don't think that what the DPL stated in that thread is fundamentally
different from what is described in dev-ref. Also, note that the DPL was
expressing his opinion, and that, because the DPL expresses an opinion,
it does not necessarily become the opinion of the project.

The current policy on NMUs was defined after long and heated
discussions (please read them to get an idea). It is a compromise
between various positions.

> > > - States that leaving an open grave bug might be better than possibly
> > > uploading a version that breaks something else
> > 
> > that's correct
> 
> Try to read between the lines -- it implies "be reluctant to do an NMU unless 
> you're absolutely sure of what you're doing".  That's a much higher bar than 
> the spirit that I think is embodied in Zack's email describing NMUs.
> 
> And there's a difference between being correct and being informative.  i.e. 
> just because a statement is correct doesn't mean it conveys what DDs need to 
> know.
> 
> > > - Implies that the NMU package shouldn't make any changes other than some
> > > time of critical bug fix -- quoting: "Fixing cosmetic issues or changing
> > > the packaging style in NMUs is discouraged."
> > 
> > You are over-reading.
> 
> Saying this is not helpful.

Seriously, if the dev-ref states:
> Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.
And you understand:
> the NMU package shouldn't make any changes other than som

Re: Proposal to update NMU section 5.11.1

2012-04-24 Thread Thijs Kinkhorst 
On Tue, April 24, 2012 08:50, Chris Knadle wrote:
>> > - States that leaving an open grave bug might be better than possibly
>> > uploading a version that breaks something else
>>
>> that's correct
>
> Try to read between the lines -- it implies "be reluctant to do an NMU
> unless you're absolutely sure of what you're doing".  That's a much
> higher bar than the spirit that I think is embodied in Zack's email
> describing NMUs.

This seems like valuable advice for any upload, including NMU's, so I
don't think this bar needs to be lowered at all, nor do I think Zack
promotes that.

> And there's a difference between being correct and being informative.
> i.e. just because a statement is correct doesn't mean it conveys what DDs
> need to know.

Is there a concrete problem with DD's misunderstanding this text?

> > - Implies that the NMU package shouldn't make any changes other than
>> some
>> > time of critical bug fix -- quoting: "Fixing cosmetic issues or
>> changing
>> > the packaging style in NMUs is discouraged."
>>
>> You are over-reading.
>
> Saying this is not helpful.

I do think Lucas is right - you are taking a rather large leap of
interpretation: from very specific ("no cosmetic changes or switching
packaging style") to rather generic ("nothing other than critical bugs").
There's a host of issues in between, they are not excluded in the text but
they are excluded in what you say the text 'implies'. I would indeed
suggest, like Lucas, not to try too hard to find 'implications' or
'between the lines' text, which isn't actually there.


Thijs


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3859cce73c8b4d7743c1c995a581e011.squir...@wm.kinkhorst.nl

Re: Proposal to update NMU section 5.11.1

2012-04-23 Thread Chris Knadle 
On Monday, April 23, 2012 18:54:41, Lucas Nussbaum wrote:
> On 23/04/12 at 17:24 -0400, Chris Knadle wrote:
> > Oops... sending again, as I forgot to CC: the developer's reference team.
> > 
> > On Monday, April 23, 2012 16:26:59, Lucas Nussbaum wrote:
> > > Hi,
> > > 
> > > On 23/04/12 at 14:56 -0400, Chris Knadle wrote:
> > > > Greetings.
> > > > 
> > > > I would like your consideration as to whether to update Section
> > > > 5.11.1 of the Developer's Reference to incorporate some of the views
> > > > of Stefano Zacchiroli concerning "When and how to do an NMU".  [1]
> > > > 
> > > > For background as to why this came up, there's recently been
> > > > discussion about several packages in Debian that are quite out of
> > > > date compared to upstream, including the WINE packages -- this
> > > > thread starts at [2].  If you browse the 'wine' source package at
> > > > [3], you can see what has transpired: there used to be several
> > > > people collaborating on the wine packages, but for whatever reason
> > > > it ended up being left to only one maintainer doing the work.  This
> > > > maintainer has stated [4] that he has time overloaded elsewhere so
> > > > that he doesn't have time to work on the packages now, but
> > > > simultaneously has QA requirements such that all of the older
> > > > pre-1.2 wine versions must be packaged first before packaging
> > > > versions 1.2 and 1.4.
> > > > 
> > > > It seems like NMU(s) on the package(s) would be a reasonable course
> > > > of action, but the current wording of Section 5.11.1 in the
> > > > Developer's Reference [5] would seem to discourage this -- or at
> > > > least that's how I personally interpret the current wording.  This
> > > > is the reason I would like to revisit this issue to see whether
> > > > updating the wording in this section would be appropriate.
> > > 
> > > Could you be a bit more specific about what you believe is not allowed
> > > to do using NMUs?
> > 
> > Not exactly, no -- the reason is that section 5.11.1 doesn't state what
> > isn't allowed with NMUs, and instead seems worded on the conservative
> > side and simply makes recommendations of when NMUs might be appropriate
> > or not.  In other words, I think the section is a little too vague, and
> > simultaneously doesn't seem to correspond with what Zack believes can be
> > done with NMUs.
> > 
> > Section 5.11.1:
> > 
> > - Seems to imply that the only reason to do an NMU is for fixing bugs. 
> > In interpreting this, it is not clear that a wishlist bug report of
> > "please package the new upstream version" is something that could be
> > valid to do an NMU for if the maintainer doesn't have time to do the
> > work.
> 
> wishlist bugs are bugs, so they are covered.

I now that *now*, but only because of discussion on [debian-devel], and not 
because of Section 5.11 of the Developer's Reference.  :-(

Let me state the issue another way -- when it comes to NMUs, my personal 
reference on them is now Zack's email, and not the Developer's Reference.  :-/  
I want others to be able to get at least the same level of understanding of 
NMUs that I currently have now after discussing it on [debian-devel], without 
having the DPL needing to repeatedly explain them.

> > - States that leaving an open grave bug might be better than possibly
> > uploading a version that breaks something else
> 
> that's correct

Try to read between the lines -- it implies "be reluctant to do an NMU unless 
you're absolutely sure of what you're doing".  That's a much higher bar than 
the spirit that I think is embodied in Zack's email describing NMUs.

And there's a difference between being correct and being informative.  i.e. 
just because a statement is correct doesn't mean it conveys what DDs need to 
know.

> > - Implies that the NMU package shouldn't make any changes other than some
> > time of critical bug fix -- quoting: "Fixing cosmetic issues or changing
> > the packaging style in NMUs is discouraged."
> 
> You are over-reading.

Saying this is not helpful.

> > Quite literally what happened in this case is Zack pointed me to read
> > Section 5.11.1 of the Developer's Reference, along with saying that NMUs
> > are more permissive than I thought they were -- and after reading the
> > section again, I came back with the same conclusion that I already had
> > because of the way it's worded.  I'm hoping to reword the section so
> > that others don't get the same mistaken impression that I had, which was
> > that Debian Developers generally don't do NMUs unless it's for an
> > Release Critical bug of some kind, and never to do NMUs for uploading a
> > new upstream version.  I'm not the only one that had this mistaken
> > impression.
> 
> I don't mean to discourage you, but converging on the current wording
> took several hundreds of mails. See http://dep.debian.net/deps/dep1.html
> and related discussions on various mailing lists back in 2008.

I'm not discouraged -- if anything I'd expect the reverse.

Re: Proposal to update NMU section 5.11.1

2012-04-23 Thread Lucas Nussbaum 
On 23/04/12 at 17:24 -0400, Chris Knadle wrote:
> Oops... sending again, as I forgot to CC: the developer's reference team.
> 
> On Monday, April 23, 2012 16:26:59, Lucas Nussbaum wrote:
> > Hi,
> > 
> > On 23/04/12 at 14:56 -0400, Chris Knadle wrote:
> > > Greetings.
> > > 
> > > I would like your consideration as to whether to update Section 5.11.1 of
> > > the Developer's Reference to incorporate some of the views of Stefano
> > > Zacchiroli concerning "When and how to do an NMU".  [1]
> > > 
> > > For background as to why this came up, there's recently been discussion
> > > about several packages in Debian that are quite out of date compared to
> > > upstream, including the WINE packages -- this thread starts at [2].  If
> > > you browse the 'wine' source package at [3], you can see what has
> > > transpired: there used to be several people collaborating on the wine
> > > packages, but for whatever reason it ended up being left to only one
> > > maintainer doing the work.  This maintainer has stated [4] that he has
> > > time overloaded elsewhere so that he doesn't have time to work on the
> > > packages now, but simultaneously has QA requirements such that all of
> > > the older pre-1.2 wine versions must be packaged first before packaging
> > > versions 1.2 and 1.4.
> > > 
> > > It seems like NMU(s) on the package(s) would be a reasonable course of
> > > action, but the current wording of Section 5.11.1 in the Developer's
> > > Reference [5] would seem to discourage this -- or at least that's how I
> > > personally interpret the current wording.  This is the reason I would
> > > like to revisit this issue to see whether updating the wording in this
> > > section would be appropriate.
> > 
> > Could you be a bit more specific about what you believe is not allowed
> > to do using NMUs?
> 
> Not exactly, no -- the reason is that section 5.11.1 doesn't state what isn't 
> allowed with NMUs, and instead seems worded on the conservative side and 
> simply makes recommendations of when NMUs might be appropriate or not.  In 
> other words, I think the section is a little too vague, and simultaneously 
> doesn't seem to correspond with what Zack believes can be done with NMUs.
> 
> Section 5.11.1:
> 
> - Seems to imply that the only reason to do an NMU is for fixing bugs.  In 
> interpreting this, it is not clear that a wishlist bug report of "please 
> package the new upstream version" is something that could be valid to do an 
> NMU for if the maintainer doesn't have time to do the work.

wishlist bugs are bugs, so they are covered.

> - States that leaving an open grave bug might be better than possibly 
> uploading a version that breaks something else

that's correct

> - Implies that the NMU package shouldn't make any changes other than some 
> time 
> of critical bug fix -- quoting: "Fixing cosmetic issues or changing the 
> packaging style in NMUs is discouraged."

You are over-reading.

> Quite literally what happened in this case is Zack pointed me to read Section 
> 5.11.1 of the Developer's Reference, along with saying that NMUs are more 
> permissive than I thought they were -- and after reading the section again, I 
> came back with the same conclusion that I already had because of the way it's 
> worded.  I'm hoping to reword the section so that others don't get the same 
> mistaken impression that I had, which was that Debian Developers generally 
> don't do NMUs unless it's for an Release Critical bug of some kind, and never 
> to do NMUs for uploading a new upstream version.  I'm not the only one that 
> had this mistaken impression.

I don't mean to discourage you, but converging on the current wording
took several hundreds of mails. See http://dep.debian.net/deps/dep1.html
and related discussions on various mailing lists back in 2008.

Lucas


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120423225441.ga7...@xanadu.blop.info

Re: Proposal to update NMU section 5.11.1

2012-04-23 Thread Chris Knadle 
Oops... sending again, as I forgot to CC: the developer's reference team.

On Monday, April 23, 2012 16:26:59, Lucas Nussbaum wrote:
> Hi,
> 
> On 23/04/12 at 14:56 -0400, Chris Knadle wrote:
> > Greetings.
> > 
> > I would like your consideration as to whether to update Section 5.11.1 of
> > the Developer's Reference to incorporate some of the views of Stefano
> > Zacchiroli concerning "When and how to do an NMU".  [1]
> > 
> > For background as to why this came up, there's recently been discussion
> > about several packages in Debian that are quite out of date compared to
> > upstream, including the WINE packages -- this thread starts at [2].  If
> > you browse the 'wine' source package at [3], you can see what has
> > transpired: there used to be several people collaborating on the wine
> > packages, but for whatever reason it ended up being left to only one
> > maintainer doing the work.  This maintainer has stated [4] that he has
> > time overloaded elsewhere so that he doesn't have time to work on the
> > packages now, but simultaneously has QA requirements such that all of
> > the older pre-1.2 wine versions must be packaged first before packaging
> > versions 1.2 and 1.4.
> > 
> > It seems like NMU(s) on the package(s) would be a reasonable course of
> > action, but the current wording of Section 5.11.1 in the Developer's
> > Reference [5] would seem to discourage this -- or at least that's how I
> > personally interpret the current wording.  This is the reason I would
> > like to revisit this issue to see whether updating the wording in this
> > section would be appropriate.
> 
> Could you be a bit more specific about what you believe is not allowed
> to do using NMUs?

Not exactly, no -- the reason is that section 5.11.1 doesn't state what isn't 
allowed with NMUs, and instead seems worded on the conservative side and 
simply makes recommendations of when NMUs might be appropriate or not.  In 
other words, I think the section is a little too vague, and simultaneously 
doesn't seem to correspond with what Zack believes can be done with NMUs.

Section 5.11.1:

- Seems to imply that the only reason to do an NMU is for fixing bugs.  In 
interpreting this, it is not clear that a wishlist bug report of "please 
package the new upstream version" is something that could be valid to do an 
NMU for if the maintainer doesn't have time to do the work.

- States that leaving an open grave bug might be better than possibly 
uploading a version that breaks something else

- Implies that the NMU package shouldn't make any changes other than some time 
of critical bug fix -- quoting: "Fixing cosmetic issues or changing the 
packaging style in NMUs is discouraged."



Quite literally what happened in this case is Zack pointed me to read Section 
5.11.1 of the Developer's Reference, along with saying that NMUs are more 
permissive than I thought they were -- and after reading the section again, I 
came back with the same conclusion that I already had because of the way it's 
worded.  I'm hoping to reword the section so that others don't get the same 
mistaken impression that I had, which was that Debian Developers generally 
don't do NMUs unless it's for an Release Critical bug of some kind, and never 
to do NMUs for uploading a new upstream version.  I'm not the only one that 
had this mistaken impression.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.

Re: Proposal to update NMU section 5.11.1

2012-04-23 Thread Lucas Nussbaum 
Hi,

On 23/04/12 at 14:56 -0400, Chris Knadle wrote:
> Greetings.
> 
> I would like your consideration as to whether to update Section 5.11.1 of the 
> Developer's Reference to incorporate some of the views of Stefano Zacchiroli 
> concerning "When and how to do an NMU".  [1]
> 
> For background as to why this came up, there's recently been discussion about 
> several packages in Debian that are quite out of date compared to upstream, 
> including the WINE packages -- this thread starts at [2].  If you browse the 
> 'wine' source package at [3], you can see what has transpired: there used to 
> be several people collaborating on the wine packages, but for whatever reason 
> it ended up being left to only one maintainer doing the work.  This 
> maintainer 
> has stated [4] that he has time overloaded elsewhere so that he doesn't have 
> time to work on the packages now, but simultaneously has QA requirements such 
> that all of the older pre-1.2 wine versions must be packaged first before 
> packaging versions 1.2 and 1.4.
> 
> It seems like NMU(s) on the package(s) would be a reasonable course of 
> action,  
> but the current wording of Section 5.11.1 in the Developer's Reference [5] 
> would seem to discourage this -- or at least that's how I personally 
> interpret 
> the current wording.  This is the reason I would like to revisit this issue 
> to 
> see whether updating the wording in this section would be appropriate.

Could you be a bit more specific about what you believe is not allowed
to do using NMUs?

Lucas


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120423202659.ga...@xanadu.blop.info

Proposal to update NMU section 5.11.1

2012-04-23 Thread Chris Knadle 
Greetings.

I would like your consideration as to whether to update Section 5.11.1 of the 
Developer's Reference to incorporate some of the views of Stefano Zacchiroli 
concerning "When and how to do an NMU".  [1]

For background as to why this came up, there's recently been discussion about 
several packages in Debian that are quite out of date compared to upstream, 
including the WINE packages -- this thread starts at [2].  If you browse the 
'wine' source package at [3], you can see what has transpired: there used to 
be several people collaborating on the wine packages, but for whatever reason 
it ended up being left to only one maintainer doing the work.  This maintainer 
has stated [4] that he has time overloaded elsewhere so that he doesn't have 
time to work on the packages now, but simultaneously has QA requirements such 
that all of the older pre-1.2 wine versions must be packaged first before 
packaging versions 1.2 and 1.4.

It seems like NMU(s) on the package(s) would be a reasonable course of action,  
but the current wording of Section 5.11.1 in the Developer's Reference [5] 
would seem to discourage this -- or at least that's how I personally interpret 
the current wording.  This is the reason I would like to revisit this issue to 
see whether updating the wording in this section would be appropriate.



[1] http://lists.debian.org/debian-devel/2012/04/msg00486.html

[2] http://lists.debian.org/debian-devel/2012/04/msg00280.html

[3] http://packages.qa.debian.org/w/wine.html

[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585409

[5] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-
guidelines



Thanks.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.