Re: GIT for linux-2.6
On Mon, Dec 13, 2010 at 01:15:01AM +0000, Ben Hutchings wrote:
> On Sun, 2010-12-12 at 19:52 +0100, Bastian Blank wrote:
> > Featureset can be included as different branches. While we don't have
> > any featuresets planned for Wheezy for the time beeing, I don't want to
> > loose the support for them.
> I wonder what we should do when there are merge conflicts with a
> featureset. These are usually simple textual conflicts that can be
> resolved without deep understanding of the code, but a while ago there
> were some scheduler changes in a stable update that had to be deferred
> for OpenVZ and VServer until they were resolved upstream. How would we
> handle this in future? Would we have to defer applying the entire
> stable update for that featureset?
No idea. We could revert the problematic changes until it is sorted out.
But it would at least produce some non-trivial changset graphs.
> > TODO
> > * Branch names
> Name like the current subdirectories of 'dists', except 'trunk' becomes
> 'master'.
Well, the branches needs both the dist and the featureset in the name.
So it would be more like sid/main, sid/rt or so. Otherwise we need one
repository per dist or per featureset.
> > * Architecture specific patches
> Architecture-specific patches are an anti-feature.
Ack. I just wanted to list them for completeness.
> > Repository "infrastructure"
> > ===========================
> > This repository includes the infrastructure used to build the package.
> > This includes scripts for config handling, control templates, maintainer
> > scripts etc. The contents of this repository are declared independant of
> > the version of the source and the configs.
>
> This assumes we never need to make fixes to the packaging in a stable
> release, which is not true (think of reinstating LILO updates in lenny).
It would still contains branches for all the dists.
> > This script would create anything a Debian source package needs. This
> > includes patches for every source from the base version. Also it may do
> > various safety checks like out-to-dateness of the several sources.
> Do you expect to create one patch for each commit in the 'source'
> repository from the base (or post-DFSG 'orig') version? It won't be
> possible to generate a linear series like this, in general.
>
> I expect to generate at most one patch for each stable update, one for
> all changes beyond that (other than featuresets), and one for each
> featureset.
We can generate one patch for all the changes in one tree, and another
for every featureset. Or patches per stable update. I did not think
about that yet.
> > A submodule reference does not keep objects alive. So without some extra
> > care, commits in the submodules may disappear.
> Doesn't that imply that the submodules should be tagged at the same
> time?
That would make it easier I think. But the tags in the submodules should
be done by some scripts instead of manually.
Bastian
--
"We have the right to survive!"
"Not by killing others."
-- Deela and Kirk, "Wink of An Eye", stardate 5710.5
Reply to: