[Pkg-shadow-devel] Policy for patches in the sid branch

[Christian Perrier]

Quoting Nicolas Fran=E7ois (nicolas.francois@centraliens.net):
>  * This dpatch will depends on the 1xx patches, so I had to create a
>    00list file in debian/patches.
>    Should this 00list file be present in the CVS?

Yes, if I understand well its purpose. Could you quickly elaborate?

>=20
>  * The header of the dpatch generated by dpatch-edit-patch looks rather
>    different from the ones in the debian/patches directory.  Does it
>    depend on a configuration variable (maybe a 00template file)?

All files in debian/patches are manually generated..:-). I know, I'm
dumb, this is a very well known fact...

I'm not even very clever about dpatch tools as my only goal was
getting together these patches so I took one package using dpatch as
example, but indeed I'm not deeply familiar with these tools.

So, it doesn't matter if the header is different. And, please, feel
free to document your use of dpatch to produce nice patches in
README.patches..:-)

>  * How to test once the dpatch is created?
>    (Here again, to dpatch apply-all, a 00list file seems to be needed)
>=20
> > Alexander and I have confirmed that using it and applying all its
> > patches lead to the exact same source tree than what we have currentl=
y
> > in the Debian archive (4.0.4-31sarge2).
>=20
> Do we commit new patches (in the Sid branch)?
> (I'm asking this because it will break the equivalence with
> 4.0.4-31sarge2).
> I would anyway rather like a review for my first dpatches.

Well, if all things that break the equivalence with 31sarge2 are
numbered in a way which easily allows to remove them before building,
this is not a problem.

We should find a way to handle debian/changelog, however. At this
moment, it has the 3xx patches listed, but if we first build a -32
version which is only a "switch to dpatch" version, we will have to
edit it and keep the post-32 stuff elsewhere temporarily.

Maybe a debian/changelog-post32 file would be better?


> > In short, while we are working towards synchronisation with upstream,
> > our goal is to make 0xx patches disappear by moving them either to 3x=
x
> > series (things already implemented upstream) or to 4xx series
> > (Debian-specific patches).
>=20
> I think you mean splitting 0xx patches to logical sub-patches.
> Do you recommend a way of using dpatch tools for splitting the 0xx
> patches?
> Here is how I intent to do this:
>  * De-aply the 0xx patch (only one, all, some)
>  * create a new dpatch and pick some of the changes
> (* update the 0xx patch(es) involved in this logical sub-patch)

Yes, that's more or less the way I think we should work. Indeed, being
dumb, I imagined doing this manually, starting with the manpages patch
probably (one man page patch per dpatch file).

But, you certainly have better ideas there, so feel free to apply them.

> Another points non related to dpatch:
> The debian changelog seems to contain lines starting by a tabulation.
> My beloved vim seems to choke on these lines (colored in red).
> Maybe these tabulations should be expanded.

Yep. I'm not good at keeping consistency here. Again, feel free to
clean up my mess.

> Would you like to have CVS commits notifications?

You mean automated CVS commit notifications in the list or just manual
mails from you when you commit something?

>=20
>=20
> BTW, thanks for permitting to test dpatch.  It's really nice!
> (subliminal note: quilt is still on my "to be tested" list)

This is also Martin Quinson idea (Martin is lurking here and he
already mentioned me that "dpatch sucks and quilt is better"....which
I answered him that I actually don't care about the system but rather
about the amount of triage work we have)

So, well, technology changes should be delayed.....later..:-)