[CVS] `br_woody_exp' created, I'm a GNU rewrite the Makefiles.


Subject: [CVS] `br_woody_exp' created, I'm a GNU rewrite the Makefiles.
From: Karl M. Hegbloom (karlheg@bittersweet.inetarena.com)
Date: Sat Mar 04 2000 - 15:58:45 CET


 I ran the following commands just now:

   export CVSROOT=:ext:karlheg@cvs.debian.org:/cvs/debian-boot

   cvs -Q rtag -b br_woody_exp boot-floppies

   cvs -Q rtag -r br_woody_exp woody_exp_branchpoint boot-floppies

   cvs -Q rtag -r woody_exp_branchpoint woody_exp_last_joinpoint boot-floppies

 `br' means "this is a branch tag", and `exp' means "experimental".

  ... (And Woody says he's Guh-noo...)

 I tagged the branchpoint so we can find it again, and also dropped a
 tag for the last joinpoint, so that it will be possible to do:

 (Note that I have *NOT* run any of the commands below this line today.)

   cvs -Q rtag -r HEAD woody_exp_tmp boot-floppies

   cvs update -j woody_exp_last_joinpoint -j woody_exp_tmp

   cvs -Q rtag -F -r woody_exp_tmp woody_exp_last_joinpoint boot-floppies

   cvs -Q rtag -d woody_exp_tmp boot-floppies

 The `tmp' tag is for just in case someone else commits something
 between performing the join and moving the joinpoint tag forward.

 When we release Potato, one of us will run:

   cvs -Q rtag br_potato_rel boot-floppies

   cvs -Q rtag -r br_potato_rel potato_rel_branchpoint boot-floppies

   cvs -Q rtag -r potato_rel_branchpoint potato_rel_last_joinpoint boot-floppies

 `rel' means "released"

 At that point, the `br_woody_exp' can be joined to the trunk and the
 woody experiment branch terminated. (not deleted, mind you, but
 terminated, like an ethernet cable, with a final ChangeLog entry and
 commit.)

 The reason I've done this is that I've begun redesigning and
 rewriting the toplevel Makefile, and things like that... (a series of
 rules.* files, one for each arch, possible support for Hurd
 envisioned, &c; you'll see it soonish; I'll email the list.) and
 don't think it would be wise to try and debug what I'm planning in
 time for the potato release... or to try and rush it -- it will take
 me a week or so just to get a decent framework started, and longer to
 flesh out enough that it builds `boot-floppies'. I'm going to move
 the tree I'm working in over to the branch with:

   cvs update -r br_woody_exp

 ... and check out the HEAD revision again in another directory, for
 work on the Potato set (that I promised I'd do, that led to the
 branch, because things are such a "well planned" mess right now...)

 It's at the stage where we can step back from it and see ways to
 improve its organization, now that we know what "all" it has to do in
 each of several situations... Anyway, there's an experiment branch
 with Woody's name on it now, and within a few days, I'll commit some
 new makefile stuff there.

 One of the things I will write is `rules.cvs_control'. It will have
 some targets defined for performing things like the above set of
 commands.

 I would like to easily be able to customize the base set, and provide
 support for creating custom pre-configured installations, &c. Many
 of us stand to profit by it. (If I get nothing else from this, it's
 work experience.)

<topic-switch>

 For the graphical installer, I think we should stick to XFree86 and
 the xserver-vga16 with a simple lowres lowcolor Gtk+ (glade)
 interface. Perhaps `XF86Setup' could be rewritten to use Gtk+ rather
 than Tk? That would be pretty nifty. `xvidtune' needs a face lift
 also. Go graphical (X) only when installing from CD-ROM, mounted
 partition, or NFS. Perhaps `dbootstrap_g' can be used from a floppy
 install though.

 If the graphical base set has everything but the actual video driver
 plugin, then it could ask about your hardware, install the right
 driver package, configure the X server, then go to a fancier (higher
 resolution, more colors) interface. Gnome-Apt is looking pretty good
 these days.

-- 
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



This archive was generated by hypermail 2b25 : Sat Mar 04 2000 - 16:01:12 CET