> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
