|
|
 Up |
|
|
  |
Author: Lucas NussbaumLucas Nussbaum Date: May 31, 2008 03:30
Hi,
In an effort to move the discussion forward, here is a new version of
the proposed section 5.11.1. (Bas Wijnen didn't have a chance to have a
look at this yet)
It tries to address the comments about communication with the maintainer
prior to the NMU, and about giving some time to the maintainer to react.
Steve, Manoj, Charles, Richard, does this address your concerns?
If not, can you propose some additional changes?
-------------
5.11.1 When and how to do an NMU
Before doing an NMU, consider the following questions:
* Do you really fix bugs in your NMU? Fixing cosmetic issues, or
changing the packaging style in NMUs is discouraged, unless it
is required to fix bugs.
* Did you give enough time to...
|
| Show full article (3.39Kb) |
|
| | 40 Comments |
|
|
Author: Charles PlessyCharles Plessy Date: May 31, 2008 08:30
Le Sat, May 31, 2008 at 12:20:55PM +0200, Lucas Nussbaum a écrit :
>
> Unless you have an excellent reason not to do so, you must then give some
> time to the maintainer to react
Hi Lucas,
excellence is definitely what we should aim for :)
Thank you for your efforts. Here are my last comments on the DEP:
5.11.1 When and how to do an NMU
I propose to add "NMUs are usually not appropriate for team-maintained
packages. Consider sending a patch to the BTS instead." to the bullet
list.
5.11.1.2 Using the DELAYED/ queue
I propose to ask a paragraph saying:
"If you do not make your NMU to DELAYED/, you must document your reasons
in the BTS."
I and others had NMUs on non-RC bugs on team-maintained packages while
being active and we are still left to wonder what in our packaging
practice was so wrong that it had to be fixed in emergency. Having the
reason written in the BTS would help us to improve ourselves.
|
| Show full article (2.07Kb) |
|
| | no comments |
|
|
Author: Lucas NussbaumLucas Nussbaum Date: May 31, 2008 09:20
On 01/06/08 at 00:22 +0900, Charles Plessy wrote:
> Le Sat, May 31, 2008 at 12:20:55PM +0200, Lucas Nussbaum a écrit :
>>
>> Unless you have an excellent reason not to do so, you must then give some
>> time to the maintainer to react
>
> Hi Lucas,
>
> excellence is definitely what we should aim for :)
>
> Thank you for your efforts. Here are my last comments on the DEP:
>
>
> 5.11.1 When and how to do an NMU
>
> I propose to add "NMUs are usually not appropriate for team-maintained
> packages. Consider sending a patch to the BTS instead." to the bullet
> list.
|
| Show full article (3.44Kb) |
| no comments |
|
|
Author: Frans PopFrans Pop Date: May 31, 2008 09:50
On Saturday 31 May 2008, Lucas Nussbaum wrote:
>> I propose to add "NMUs are usually not appropriate for
>> team-maintained packages. Consider sending a patch to the BTS
>> instead." to the bullet list.
>
> It really depends on the team. There are small teams where all members
> might become unresponsive at the same time. I don't think that we
> should special-case this.
Yes, it probably does depend on the team. But several people have raised
this point now, which probably means that it _is_ a real concern. When
are you (the proposers of this DEP) going to start listening to your
peers instead of dismissing their concerns?
A lot of packages are team-maintained not only because it is more fun to
work together, but also because those packages (or groups of packages)
are more complex, or have interactions that may not be obvious at first
glance. Which means that there may well be a bigger likelyhood that an
NMU will break things.
|
| Show full article (1.38Kb) |
| no comments |
|
|
Author: Luk ClaesLuk Claes Date: May 31, 2008 10:00
Frans Pop wrote:
> On Saturday 31 May 2008, Lucas Nussbaum wrote:
>>> I propose to add "NMUs are usually not appropriate for
>>> team-maintained packages. Consider sending a patch to the BTS
>>> instead." to the bullet list.
>> It really depends on the team. There are small teams where all members
>> might become unresponsive at the same time. I don't think that we
>> should special-case this.
>
> Yes, it probably does depend on the team. But several people have raised
> this point now, which probably means that it _is_ a real concern. When
> are you (the proposers of this DEP) going to start listening to your
> peers instead of dismissing their concerns?
>
> A lot of packages are team-maintained not only because it is more fun to
> work together, but also because those packages (or groups of packages)
> are more complex, or have interactions that may not be obvious at first
> glance. Which means that there may well be a bigger likelyhood that an
> NMU will break things.
> ...
|
| Show full article (1.59Kb) |
| no comments |
|
|
Author: Frans PopFrans Pop Date: May 31, 2008 10:20
On Saturday 31 May 2008, Luk Claes wrote:
>> "All members of a team becoming unresponsive" is possible, agreed.
>> But it is a hell of a lot less likely than "at least one member of
>> the team being able to respond to urgently needed changes if
>> appropriately notified".
>
> So, why should there be any special treatment as they are more likely
> to respond early anyway? Or are you questioning normal NMU intents,
> RC/RG bugs and d-d-a announcements as appropriate notifications?
Because bugs may also have been (or seem to have been overlooked). The
risk here is that the person doing the NMU thinks "oh, that's an old
issue and the fix seems so simple" and goes ahead and NMUs it, while
there may be very valid reasons for not fixing it (or at least not with
_that_ fix).
A follow-up to the bug report with just "hey, this issue seems to be
forgotten, could someone please take another look as it seems important"
would then be a lot more appropriate and take a lot less time all around
then preparing the patch, uploading it to delayed and then getting to
hear "sorry, this is not good, please remove your NMU from the queue".
|
| Show full article (2.00Kb) |
| no comments |
|
|
Author: Lucas NussbaumLucas Nussbaum Date: May 31, 2008 10:30
On 31/05/08 at 18:44 +0200, Frans Pop wrote:
> On Saturday 31 May 2008, Lucas Nussbaum wrote:
>>> I propose to add "NMUs are usually not appropriate for
>>> team-maintained packages. Consider sending a patch to the BTS
>>> instead." to the bullet list.
>>
>> It really depends on the team. There are small teams where all members
>> might become unresponsive at the same time. I don't think that we
>> should special-case this.
>
> Yes, it probably does depend on the team. But several people have raised
> this point now, which probably means that it _is_ a real concern.
|
| Show full article (3.33Kb) |
| no comments |
|
|
Author: Luk ClaesLuk Claes Date: May 31, 2008 10:50
Frans Pop wrote:
> On Saturday 31 May 2008, Luk Claes wrote:
>>> "All members of a team becoming unresponsive" is possible, agreed.
>>> But it is a hell of a lot less likely than "at least one member of
>>> the team being able to respond to urgently needed changes if
>>> appropriately notified".
>> So, why should there be any special treatment as they are more likely
>> to respond early anyway? Or are you questioning normal NMU intents,
>> RC/RG bugs and d-d-a announcements as appropriate notifications?
>
> Because bugs may also have been (or seem to have been overlooked). The
> risk here is that the person doing the NMU thinks "oh, that's an old
> issue and the fix seems so simple" and goes ahead and NMUs it, while
> there may be very valid reasons for not fixing it (or at least not with
> _that_ fix).
>
> A follow-up to the bug report with just "hey, this issue seems to be
> forgotten, could someone please take another look as it seems important"
> would then be a lot more appropriate and take a lot less time all around
> then preparing the patch, uploading it to delayed and then getting to ...
|
| Show full article (2.16Kb) |
| no comments |
|
|
Author: Manoj SrivastavaManoj Srivastava Date: May 31, 2008 11:00
On Sat, 31 May 2008 12:20:55 +0200, Lucas Nussbaum
lucas-nussbaum.net> said:
> Steve, Manoj, Charles, Richard, does this address your concerns? If
> not, can you propose some additional changes?
This new version does sound a lot better.
manoj
--
If voting could really change things, it would be illegal. Revolution
Books. New York, New York.
Manoj Srivastava debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
|
| |
| no comments |
|
|
|
|
|
Author: Frans PopFrans Pop Date: May 31, 2008 11:50
On Saturday 31 May 2008, Lucas Nussbaum wrote:
> * Have you clearly expressed your intention to NMU, at least on the
> BTS? Has the maintainer been notified of it? It is also a good
> idea to try to contact the maintainer by other means (private
> email, IRC)
IMO private mail is the wrong way to do this if the intention to NMU has
already been registered in the BTS. Maintainers can be expected to read
BTS mails for their packages [1]. Sending a private mail is not something
I would ever do I think.
A final attempt to ping on IRC can be appropriate in some cases.
Cheers,
FJP
[1] With one exception: mails with large attachments may be accepted by
the BTS, but not reach the maintainer. For example, lists.d.o has a size
limit, while bugs.d.o does not (#475682).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
|
| Show full article (1.00Kb) |
| no comments |
|
|
|
|
