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

[Alexander Gattin]

Hi!

> > > P.S. Also, what is the policy for patching
> > > Debian-specific stuff, like remove-shell? I just

Here I mean Debian-specific files that are in debian/
subdir.

> > > changed the file in CVS under pkg-shadow/sid/
> > > directory.
> > > 
> > > We should rather document this.
> > 
> > Yes, the diff showed this.
> > 
> > IMO, this is OK at least as soon as the diff in very small.

I can change pkg-shadow/sid/debian/remove-shell.sh back
to original state and convert changes into .dpatch file
instead. It will take just a couple of minutes.

> > So that we will be able to review the difference between the generated
> > package with dpatch and 31sarge2.

If we will have 2 CVS branches (SID and SARGE) we will
be able to do it too.

> Absolutely.
> 
> Indeed, I'm more and more thinking about building -32 ASAP and upload
> it to unstable.

When having several branches in CVS, the only important
thing is to _always stick_ to some branch and not use
default HEAD one. Because it can have files mixed from
several branches and/or miss some files.

Once you have done `cvs co -r SID`, tag SID becomes
"sticky" for working directory (checked out).

You can switch to another branch from inside working
directory by issuing `cvs update -rSARGE` -- all files
will be updated/added/deleted as needed.

You can merge changes done in another branch to working
directory with `cvs update -j1.1.1.7 -jSID`

I use this for maintaining some local debianized
packages (iproute2 among them) and syncing with
upstream.

Usually everything is done quite fast in such a
manner...

> This will force us to do sarge uploads to t-p-u but that's not a big
> deal.

What is t-p-u?

P.S. let's decide with sarge-by-dpatch equivalence -- I
propose to do it by forking a branch from sid/.

Also, would you like me to convert remove-shell.sh
changes to .dpatch file?
-- 
WBR,
xrgtn