|
|
 Up |
|
|
  |
Author: Thijs KinkhorstThijs Kinkhorst Date: Aug 19, 2008 12:30
Hi,
Sorry for breaking the thread and chiming in late, I was until recently not
aware of this thread and not subscribed to debian-project. I hope my comments
can still be considered.
> The version must be the version of the last upload, plus +nmuX,
> This special versioning is needed to avoid stealing one of the
> package maintainer's version numbers, which might disrupt their
> work.
The past weeks I had several encounters with the situation that a maintainer
completely overlooked and NMU and uploaded a newer version without
acknowledging the previous NMU, thereby reintroducing the problem the NMU
addressed. This happened to active maintainers.
I was wondering why we version NMU's differently from MU's. If they used the
same scheme, in these cases the subsequent upload from the MU would have been
rejected. That would have flagged a problem for them and they had discovered
the NMU they forgot to integrate. Of course it wouldn't help in any situation
but it would have helped these.
|
| Show full article (3.59Kb) |
|
| | 15 Comments |
|
|
Author: Raphael HertzogRaphael Hertzog Date: Aug 20, 2008 00:40
On Tue, 19 Aug 2008, Thijs Kinkhorst wrote:
> The past weeks I had several encounters with the situation that a maintainer
> completely overlooked and NMU and uploaded a newer version without
> acknowledging the previous NMU, thereby reintroducing the problem the NMU
> addressed. This happened to active maintainers.
At least the BTS automatically reopens the bugs so the problem doesn't
stay unnotified and untracked.
> I was wondering why we version NMU's differently from MU's. If they used the
> same scheme, in these cases the subsequent upload from the MU would have been
> rejected. That would have flagged a problem for them and they had discovered
> the NMU they forgot to integrate. Of course it wouldn't help in any situation
> but it would have helped these.
The maintainer is still king and if he decides that the NMU was not a good
idea, he would have no other choice than skipping a revision in the
changelog. That would be confusing.
Furthermore, as we encourage usage of the delayed queue, it seems natural
to avoid collision between the NMU upload and a maintainer upload
integrating the NMU done before the end of the delay.
|
| Show full article (3.91Kb) |
|
| | no comments |
|
|
Author: Lars WirzeniusLars Wirzenius Date: Aug 20, 2008 01:30
ke, 2008-08-20 kello 09:38 +0200, Raphael Hertzog kirjoitti:
> The maintainer is still king and if he decides that the NMU was not a good
> idea, he would have no other choice than skipping a revision in the
> changelog. That would be confusing.
It would, however, make things a bit more explicit than what happens
now.
|
| |
| no comments |
|
|
Author: Lucas NussbaumLucas Nussbaum Date: Aug 20, 2008 02:10
On 20/08/08 at 09:38 +0200, Raphael Hertzog wrote:
> On Tue, 19 Aug 2008, Thijs Kinkhorst wrote:
>> The past weeks I had several encounters with the situation that a maintainer
>> completely overlooked and NMU and uploaded a newer version without
>> acknowledging the previous NMU, thereby reintroducing the problem the NMU
>> addressed. This happened to active maintainers.
>
> At least the BTS automatically reopens the bugs so the problem doesn't
> stay unnotified and untracked.
It doesn't really reopen the bug. But the BTS version-tracking allows to
find out that the bug is not fixed in the new maintainer upload.
>>> If you upload a package to testing or stable, you sometimes need
>>> to "fork" the version number tree. This is the case for security
>>> uploads, for example. For this, a version of...
|
| Show full article (2.83Kb) |
| no comments |
|
|
Author: Thijs KinkhorstThijs Kinkhorst Date: Aug 20, 2008 04:40
On Wednesday 20 August 2008 10:06, Lucas Nussbaum wrote:
> On 20/08/08 at 09:38 +0200, Raphael Hertzog wrote:
>> On Tue, 19 Aug 2008, Thijs Kinkhorst wrote:
>>> The past weeks I had several encounters with the situation that a
>>> maintainer completely overlooked and NMU and uploaded a newer version
>>> without acknowledging the previous NMU, thereby reintroducing the
>>> problem the NMU addressed. This happened to active maintainers.
>>
>> At least the BTS automatically reopens the bugs so the problem doesn't
>> stay unnotified and untracked.
>
> It doesn't really reopen the bug. But the BTS version-tracking allows to
> find out that the bug is not fixed in the new maintainer upload.
That has the drawback of not notifying the maintainer explicitly directly
after (or even before) the upload.
|
| Show full article (3.01Kb) |
| no comments |
|
|
Author: Raphael HertzogRaphael Hertzog Date: Aug 20, 2008 05:20
On Wed, 20 Aug 2008, Thijs Kinkhorst wrote:
> But perhaps we need another mechanism to signal this. Consecutive uploads to
> the same distribution should not cause previously present version entries to
> disappear from the changelog. Maybe the archive can reject an upload that
> misses a changelog entry that was previously present in the uploads to this
> distribution.
Well, it still forces the inclusion of information for a revision whose
changes have been fully reverted.
I can sympathize with it on the basis that it's better to document
in a subsequent changelog entry that the NMU has been fully reverted
and to explain why.
But what about mis-targeted uploads? You upload the experimental version
to unstable by error. When you want to revert that, you upload the
previous package with an epoch and the upload gets rejected because you
dropped the experimental changelog... that would be counter-productive
too.
|
| Show full article (3.06Kb) |
| no comments |
|
|
Author: Felipe SatelerFelipe Sateler Date: Aug 20, 2008 16:40
Raphael Hertzog wrote:
> It works well except when the same package version is in two consecutive
> release.
>
> 1.0-1+sarge1 > 1.0-1+etch1 when we really want the opposite. That's why
> this scheme was invented. I agree that it's not very nice though but i
> couldn't find anything "cleaner".
Should this be happening? If something warrants a stable update, it certainly
warrants an upload to unstable (which hopefully won't use the +codename1
notation).
--
Felipe Sateler
|
| |
| no comments |
|
|
Author: Steve LangasekSteve Langasek Date: Aug 20, 2008 17:00
On Wed, Aug 20, 2008 at 07:35:51PM -0400, Felipe Sateler wrote:
> Raphael Hertzog wrote:
>> It works well except when the same package version is in two consecutive
>> release.
>> 1.0-1+sarge1 > 1.0-1+etch1 when we really want the opposite. That's why
>> this scheme was invented. I agree that it's not very nice though but i
>> couldn't find anything "cleaner".
> Should this be happening? If something warrants a stable update, it certainly
> warrants an upload to unstable (which hopefully won't use the +codename1
> notation).
This is an issue when stable and /oldstable/ both have the same version
because there were no intervening uploads to unstable. Uploading to
unstable afterwards doesn't change the fact that dpkg --compare-versions
sarge gt etch.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ ubuntu.com vorlon@ debian.org
|
| Show full article (1.22Kb) |
| no comments |
|
|
Author: Steve LangasekSteve Langasek Date: Aug 21, 2008 01:40
On Wed, Aug 20, 2008 at 01:33:16PM +0200, Thijs Kinkhorst wrote:
> That has the drawback of not notifying the maintainer explicitly directly
> after (or even before) the upload.
> But perhaps we need another mechanism to signal this. Consecutive uploads to
> the same distribution should not cause previously present version entries to
> disappear from the changelog. Maybe the archive can reject an upload that
> misses a changelog entry that was previously present in the uploads to this
> distribution.
No, this is a terrible idea. If someone uploads a bad NMU of one of my
packages, why should I have to reference it at all when superseding it?
Neither the archive nor policy should impose such a requirement on me.
> The NMU changelog entry should always be there, else the BTS will start to
> display incorrect information.
Then it's incumbent on the maintainer to correct the information.
> Say the NMU'ed fix migrated to testing and the maintainer uploads another
> fix to unstable, leaving out the changelog entry, testing is marked as
> affected again which it isn't.
That's not true. Testing will only be marked as affected when the
maintainer upload reaches testing. Which AFAICS is perfectly appropriate.
|
| Show full article (1.68Kb) |
| no comments |
|
|
|
|
|
Author: Thijs KinkhorstThijs Kinkhorst Date: Aug 21, 2008 02:00
On Thu, August 21, 2008 10:33, Steve Langasek wrote:
> On Wed, Aug 20, 2008 at 01:33:16PM +0200, Thijs Kinkhorst wrote:
>> But perhaps we need another mechanism to signal this. Consecutive
>> uploads to the same distribution should not cause previously present
>> version entries to disappear from the changelog. Maybe the archive can
>> reject an upload that misses a changelog entry that was previously
>> present in the uploads to this distribution.
>
> No, this is a terrible idea. If someone uploads a bad NMU of one of my
> packages, why should I have to reference it at all when superseding it?
> Neither the archive nor policy should impose such a requirement on me.
My concept of the package changelog is to give a chronological account of
the changes that happened to the package.
When your co-maintainer adds and uploads some patch which you in a later
upload decide to revert, you don't edit it out that old changelog entry,
but rather add a new entry stating that you reverted patch p because of
reason r. Right? I'm not clear why that would be different for NMU's. The
changelog primarily documents what changed, who exactly did that is of low
importance to the user.
|
| Show full article (2.37Kb) |
| no comments |
|
|
|
|
