Hi,

When a new upstream version is released, I have to check all patches if
they were accepted by upstream or not. I have to check each patch if I
can drop it. It would make packaging new releases easier if there were
an optional Applied-Upstream field. Every patch that was applied
upstream can be dropped. "no" or "not-yet" would indicate that the patch
was not applied yet. If the patch was applied, it could contain the
revision (like "r4681") or a link to the VCS commit.

What do you think about my suggestion?

--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)

Hi,

On Mon, 23 Nov 2009, Benjamin Drung wrote:
> When a new upstream version is released, I have to check all patches if
> they were accepted by upstream or not. I have to check each patch if I
> can drop it. It would make packaging new releases easier if there were
> an optional Applied-Upstream field. Every patch that was applied
> upstream can be dropped. "no" or "not-yet" would indicate that the patch
> was not applied yet. If the patch was applied, it could contain the
> revision (like "r4681") or a link to the VCS commit.
>
> What do you think about my suggestion?

I suppose that you would want to add the field as soon as the patch is
committed upstream so that you can more easily identify patches to remove
when the next upstream version is out?

Do you expect to automate this operation?

I'm not sure we need a new field for this purpose, you could add a comment
in the description field or even change the Forwarded: URL to point to the
upstream VCS to make it clearer that it got merged.

Let's see what other people are thinking of it.

BTW, speaking of DEP-3, someone mentioned that it doesn't tell the
encoding to use. Does anyone oppose to adding a note saying that it
should aim at being ASCII-only and if that's not possible then UTF-8
should be used?

Cheers,
--
Raphaël Hertzog


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Am Montag, den 23.11.2009, 08:42 +0100 schrieb Raphael Hertzog:
> Hi,
>
> On Mon, 23 Nov 2009, Benjamin Drung wrote:
> > When a new upstream version is released, I have to check all patches
if
> > they were accepted by upstream or not. I have to check each patch if
I
> > can drop it. It would make packaging new releases easier if there
were
> > an optional Applied-Upstream field. Every patch that was applied
> > upstream can be dropped. "no" or "not-yet" would indicate that the
patch
> > was not applied yet. If the patch was applied, it could contain the
> > revision (like "r4681") or a link to the VCS commit.
> >
> > What do you think about my suggestion?
>
> I suppose that you would want to add the field as soon as the patch is
> committed upstream so that you can more easily identify patches to
remove
> when the next upstream version is out?

Yes, indeed.

> Do you expect to automate this operation?

Adding the field would be manual, but removing the patches can do a
simple script, when the next upstream release is out.

> I'm not sure we need a new field for this purpose, you could add a
comment
> in the description field or even change the Forwarded: URL to point to
the
> upstream VCS to make it clearer that it got merged.

Automating the removal would be hard then.

> BTW, speaking of DEP-3, someone mentioned that it doesn't tell the
> encoding to use. Does anyone oppose to adding a note saying that it
> should aim at being ASCII-only and if that's not possible then UTF-8
> should be used?

I think that the DEP-3 header should be in UTF-8 (ASCII would be the
subset).


--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)

Benjamin Drung <bdrung@ubuntu.com> writes:

> Hi,
>
> When a new upstream version is released, I have to check all patches if
> they were accepted by upstream or not. I have to check each patch if I
> can drop it. It would make packaging new releases easier if there were
> an optional Applied-Upstream field. Every patch that was applied
> upstream can be dropped. "no" or "not-yet" would indicate that the patch
> was not applied yet. If the patch was applied, it could contain the
> revision (like "r4681") or a link to the VCS commit.
>
> What do you think about my suggestion?

Why would the source (or VCS head) ever contain a patch that was
applied upstream? The moment the patch gets applied you simply remove
it.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow:
> Benjamin Drung <bdrung@ubuntu.com> writes:
>
> > Hi,
> >
> > When a new upstream version is released, I have to check all patches if
> > they were accepted by upstream or not. I have to check each patch if I
> > can drop it. It would make packaging new releases easier if there were
> > an optional Applied-Upstream field. Every patch that was applied
> > upstream can be dropped. "no" or "not-yet" would indicate that the patch
> > was not applied yet. If the patch was applied, it could contain the
> > revision (like "r4681") or a link to the VCS commit.
> >
> > What do you think about my suggestion?
>
> Why would the source (or VCS head) ever contain a patch that was
> applied upstream? The moment the patch gets applied you simply remove
> it.

Not until the next upstream release.

--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)

On Mon, Nov 23, 2009 at 09:18:37AM +0100, Goswin von Brederlow wrote:
> Benjamin Drung <bdrung@ubuntu.com> writes:
>
> > Hi,
> >
> > When a new upstream version is released, I have to check all patches if
> > they were accepted by upstream or not. I have to check each patch if I
> > can drop it. It would make packaging new releases easier if there were
> > an optional Applied-Upstream field. Every patch that was applied
> > upstream can be dropped. "no" or "not-yet" would indicate that the patch
> > was not applied yet. If the patch was applied, it could contain the
> > revision (like "r4681") or a link to the VCS commit.
> >
> > What do you think about my suggestion?
>
> Why would the source (or VCS head) ever contain a patch that was
> applied upstream? The moment the patch gets applied you simply remove
> it.

Ever heard of branches ?

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org