Re: RFS: plotutils -- The GNU plotutils (plotting utilities) package
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Floris Bruynooghe <fb102@soton.ac.uk> writes:
> On Wed, May 11, 2005 at 09:45:20PM +0100, Roger Leigh wrote:
>> Floris Bruynooghe <fb102@soton.ac.uk> writes:
>>
>> importantly, it doesn't document all of your changes. We don't impose
>> penalties for more detailed descriptions, so feel free to be more
>> verbose. This is of great benefit to those who are not familiar with
>> the package. For example, you "use dpatch", but you could detail
>> exactly how you are using dpatch with a description of each patch.
>
> I have detailed all (?) my changes now (from looking at my diff), I
> haven't described every patch however. Is that really desirable?
Yes. The purpose of the changelog is to inform everyone else (and
remind you later) what changes you made. I also try to explain /why/
I made the changes, since this explains to others what the rationale
and purpose of the change are. I often find myself reviewing changes
I made months or years back, and having a good explanation really
helps.
See the xserver-xfree86 changelog for a good example.
> There is always the dpatch-list-patches command. It seems ok to write
> if you modify or add a patch, but seems a bit lengthy to describe the
> ~13 patches which where already in the old .diff.gz and are now split
> off.
This is a one-off, due to the conversion to dpatch. 13 patch
descriptions is not a lot to document.
You are right in that they were already in the .diff.gz, but you are
supposed to be describing the changes you made to the packaging, which
naturally will include these files.
>> What is debian/changelog.mine? You might want to take a more careful
> <snip>
>
> Thanks, this'll learn me not to prepare a package in between two
> lectures and decide it'll be fine. I'll take my time from now on.
That's a very good idea. There really is no rush to do things. Your
package will be in Debian for many months, maybe even years, so an
extra few hours of checking and testing are well worth it in the grand
scheme of things.
[regenerating autotools]
> So I was wondering, there must be a "proper" way of handling this. I
> can't be the only one wanting to regenerate the autotools at build
> time and keep a clean upstream tree. Did I miss something obvious?
Providing you have the correct versions of the autotools, you should
be able to run them, and have the changes included in the .diff.gz,
like now. If you are having trouble, it may be best just to leave
them.
If it's not using the current versions of the autotools, and you know
how to handle them, you could convert the package to use the current
versions, and send the changes upstream (if not done in their
development branch).
>> Have you coordinated this with the QA team?
> Why (and what) would I need to ask? The developer who did the
> upload did not file an ITA and is doubtlessly buzzy with other
> things. He only noticed, just like me, that the outstanding bugs
> where easy to fix and did so. Not that I want to appear rude or so,
> but I just don't see why that would be of needed.
Well, it never hurts to let others know what you're working on, and
cooperating and coordinating work with others is rather important.
The developer who did the last upload will be somewhat familiar with
the package, and may therefore be best suited to reviewing your work,
and maybe even sponsoring it.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFChgDxVcFcaSW/uEgRAivBAJ9J/Fa9C8fHL8IHBN334zaowujVbgCg2iYc
+Qm+7pB9CbGdZVzHvuSaNkk=
=CT7C
-----END PGP SIGNATURE-----
Reply to: