Re: More git policy: xsfbs and bundled apps packages
> The apps are fairly easy. We use the upstream* branches and just extend
> it so we have individual upstream* branches for each upstream app repo.
> These all get merged in to debian as the need arises.
Is it as simple as that? The upstream apps are all separate repos, but
for our convenience we've collected them into single packages, for
instance xbase-clients (also xprint-utils and xutils). So we'd want
xbase-clients managed as only one repo, at least as far as the debian*
branches go, which conflicts with all the individual upstream* branches
for each app contained in xbase-clients. We wouldn't be able to use
git-pull in the usual way (unless git is more flexible than I realise.
Does it have a concept of "subrepos" where a subdirectory pulls from a
different repo? I presume not otherwise this would have solved the
xsfbs problem.) Cherry picking updates one-by-one would still work,
one way or another, and I imagine we're not likely to make a whole lot
of changes to the apps, so it wouldn't be a huge problem. Would be sure
to break git-buildpackage I should expect.
> xsfbs doesn't have a good solution really. We can keep a single
> repository for xsfbs and then manually merge it when we do updates. We can
> probably script that locally to make it easier when changes to xsfbs do
> happen, although I'd still like to wean us off it this next release cycle.
> We could also create a hook script to automagically pull it in, but that's
> a lot of overhead, and I think a local script is probably a better idea.
Maintaining a local script shouldn't be a problem, I think. Might be
an idea to have everyone with project write access get notified by
email when it needs updating (in case we miss an announcement on
debian-x). What ideas do we have for eliminating xsfbs?
Drew
Reply to: