Hi, On Sun, Jan 04, 2009 at 12:05:07AM +0100, Thomas Schwinge wrote:
> Only convert GNU Mach's gnumach-1-branch, GNU MIG's HEAD, GNU Hurd's > HEAD. > > With the exception of the GNU Mach Xen branch and the Hurd GSoC > branches, these are the only branches that see active development. So? No need to drop dead branches -- they can still be interesting for reference. It's not like dropping them helps with anything... > For the GNU Mach Xen branch, I'd like Samuel to tell when that one > is ready for being merged into the main GNU Mach 1 branch and then > I intend to do that merge as one big aggregated ``blob'' (i.e., > without preserving the individual development, testing, debugging, > etc. commits. The same holds for the GSoC branches. Don't do that. The whole point of a revision control system is to preserve history... A "blob" commit is unmanageable. If you think the history of the branch(es) is too messy, you can of course start a new branch, say xen-cleanup. This new branch should still contain a series of individual changes though, even if they don't reflect actual development history. (The latter is the standard practice in Linux development, BTW.) > Exclude all automatically regeneratable and Debian package maintenance > files from the conversion. > > These files are no longer present in current checkouts (general > change of policy), but they do occupy a non-insignificant amount > of space in revision history, and are not interesting with respect > to preserving their history. (They might be interesting if > someone indeed wants to build an old version, but this is a > corner-case that can be worked around easily.) > > The files will simply be excluded from the conversion. ChangeLog > entries referncing them will not be changed in flight (too > time-consuming for no net benefit). Instead a follow-up clean-up > patch will weed out all ChangeLog entries referencing them. Sounds like a lot of additional work and potential confusion, for very little benefit... > Split Hurd modules into separate repositories. I stand by what I said on this topic before: *If* we decide to make such a change, it should be done independently of the Git migration. It would hold up the migration; it would mix a purely technial action with fundamental decisions. > Rationale: split as far as it's still making sense. There is no > reason to have an interger hashing library, a pthread > implementation, an ext2 file system interpreter, libc amendments, > Hurd interfaces definition files, a library for providing an > uniform interface to Mach ports, etc. in the same repository. Is there a reason to keep them seperate?... > libihash and libpthread are shared between Hurd and Viengoos. I agree that these should be split out, but probably also not during the git migration... > Checking the state after having done a whole-repository conversion > yields several change sets that span files in more than one of the > new modules. Indeed, it's not possible to properly disentangle the modules retrospectively. So we *have* to keep the original history, even if we really want the split to happen ultimately. This is also a reason why the split should happen only after the git conversion. > * A few others are for interface changes and follow-up > adjustment in the interface-using modules (libihash rewrite, for > example). (Likewise for build system enhancements or changes, as > adding uselocale for libthreads, or adding libncursesw for > utils/console-ncurses.c, for example.) Or adding a driver for > streamio devices and adding a stanza for these in the MAKEDEV > script at the same time. Also, there are a few (notable!) > interface changes, where the aggregated documentation in `doc/' > has been updated together with committing the interface change. > Likewise for changes where the top-level TODO or tasks file has > been updated together with committing a change. All these > changes will be broken up. Future interface changes will be > done using some sort of versioning. This is the main reason why I'm not convinced the split is a good idea at all. We would need to start some proper versioning, which is quite a pain. And what would the benefit be? It's not like we ever release these modules seperately... (At least not in the forseeable future.) -antrik-
