unsubscribe

[Andre Aberer]

Thomas Schwinge <tschwinge@gnu.org> writes:

> Hello!
>
> On Mon, Dec 08, 2008 at 09:36:25AM +0100, I wrote:
>> On Thu, Nov 20, 2008 at 11:12:21AM +0100, Neal H. Walfield wrote:
>> > I'd like to propose that we move from CVS to git.
>> 
>> I intend to do the repository conversion until the end of this year.
>
> Well, that didn't work out, but here is my plan, some decisions together
> with some reasoning.
>
> 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.
>
>     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.  We can, of
>     course, also easily publish these again as separate git branches,
>     based on the new git master branch (former CVS HEAD).  Just tell me
>     what you'd like.
>
>
> Conversion will be done with CVS / RCS keyword expansion switched off.
>
>
> 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.
>
>
> Split Hurd modules into separate repositories.
>
>     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.
>
>     libihash and libpthread are shared between Hurd and Viengoos.
>     libihash is actually not at all dependent on (any sort of) the Hurd.
>
>
>     Git submodules can easily be used to construct the same checkout tree
>     again (for easy building).  This repository (the one containing the
>     submodules information) will also be the one containing the build
>     system, release stuff (if that is at all still considered for
>     inclusion), documentation (for now, until it is split up).
>
>
>     Probobably the point of splitting will simply be the separate
>     top-level subdirectories.  Perhaps things like hostmux and usermux
>     and other simple translators will be kept aggregated.  Likewise
>     libcons and console-client (and console?), or libftpconn and ftpfs
>     (but the former is also used in utils/ftp*.)
>
>
>     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.
>
>     If ChangeLog messages referencing several modules will be changed in
>     flight is not yet decided, but probably not, as that applies only to
>     a minor parts of the affected changes / files:
>
>       * The vast majority of them are from the initial imports
>         (``Formerly Makefile.~4~'' as commit message for both
>         fstests/Makefile and libiohelp/Makefile, but the changes being
>         totaly unrelated), or aggregations of Roland's and Miles' ``.''
>         and Thomas' ``*** empty log message ***'' commit messages --
>         aggregated due to the same text in the commit message, same
>         author, and within the same ``fuzzy'' time period.  Also in this
>         category are all the ``Initial import'', ``Initial revision'',
>         ``entered into RCS'' commits.
>
>       * 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.
>
>       * The same change (functionally) was done in several modules (in
>         ext2fs and fatfs, for example, or in hostmux and usermux).
>
>       * Wrong ChangeLog file used when committing a change.
>
>       * Committing unrelated changes (to several modules) in one go.
>         Also, removing several modules' dead files at the same time.
>
>       * Files moved from one module to another.
>
>         Perhaps move these to current destination place right from the
>         beginning, before doing the conversion?
>
>
> What do you think so far?
>
>
> Regards,
>  Thomas

pgpaBb_ip1Gmn.pgp
Description: PGP signature