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

[Christian Perrier]

Quoting Alexander Gattin (arg@online.com.ua):

> > > IMO, this is OK at least as soon as the diff in very small.
>=20
> 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.

No, I prefer not having .dpatch files for debian specific
stuff. Either you think the changes are safe and just leave them in
place (but DON'T FORGET debian/changelog update)...or you revert them
currently.

I will not be completely strict about -32 being exactly similar to
31-sarge2.... I just want it to be very close.

>=20
> > > So that we will be able to review the difference between the genera=
ted
> > > package with dpatch and 31sarge2.
>=20
> If we will have 2 CVS branches (SID and SARGE) we will
> be able to do it too.
>=20
> > Absolutely.
> >=20
> > Indeed, I'm more and more thinking about building -32 ASAP and upload
> > it to unstable.
>=20
> 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.

Currently, we don't really have branches. We have two separate
directories..:-). I'm not fond of branching and all that stuff,
especially because I'm not very comfortable with RSC tools and prefer
we to focus on the package life. As the sarge branch is currently
frozen, I don't really mind doing double work from time to time to get
patches in it. There should be very rare occasion to update the sarge
version anyway.

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

testing-proposed-updates

This is the place where updates to frozen packages should go when
there is already a version of the same package in sid, which should
not go in sarge.

At this moment, we don't have this problem with shadow. We still have
only one version being released. So, all updates are uploaded to sid
and I just have to request the release team to "hint" them so that
they enter sarge. This is what will happen for 31-sarge2 as soon as
the 10 days delay is finished (it should be).

However, if we upload -32 to sid, then no more further update for
sarge can be uploaded to sid....we will have to go through t-p-u
uploads. Not really a big deal, though.

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

By using *real* CVS branching, right=A0?

We may need that, at some moment, when we will have 4.0.3-* releases
leaving their lives in sid.....and will in the same time wrk on
4.0.8-* releases in the process of resyncing with upstream.

BUT, for simplicity, I prefer this to be done with fake branches, ie
just directories in the CVS. And we will move things from one to
another manually.

This may require file removal/renaming from time to time...this is the
reason fo rwhich i think that a switch to SVN could be good.

>=20
> Also, would you like me to convert remove-shell.sh
> changes to .dpatch file?

As mentioned above, no. Either leave it there or revert it.