Re: DEP1: Non Maintainer Uploads (final call for review)
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.
When leaving out such changelog entries, I have a version of the package
on my system that shows one behaviour, after upgrade another, and then
after upgrade the first behaviour again, I would check the changelog and
not find anything relevant. In fact, the previous version seems to have
disappeared completely.
What is the problem with documenting which versions were actually present
in the archive? Or with explicitly stating that a change has been undone?
That seems like very useful information for users to me.
How often does it happen that NMU's are rejected that makes it an
unreasonable burden to copy the 10 lines of changelog into yours?
>> 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.
Good, then I misunderstood how that worked, sorry.
Thijs
Reply to: