stuff for hhh

First off, don't forget HHH tomorrow, TWO HOURS LATER than usual.
Yay.

Second, it's great to finally have time for ibex again.  I think I've
figured out the whole subproject thing.  Here's what I'm thinking:

The ibex core will be GPL.  All subprojects (org.ibex.*, org.ibex.js,
org.ibex.mips2java, and org.ibex.widgets) will be LGPL or BSDL (up for
discussion).  If you want to spawn a new subproject of the ibex
project, and it's generally agreed to be useful, you can keep your
copyrights as long as you use one of those two licenses (or something
substantially similar, although it would be nice to standardize on two).

Each project will have a subdirectory in /var/www:

   /var/www/
            org/
                ibex/
                     www/      (web site "subproject")
                     widgets/
                     core/
                     js/
                     mips2java/
                     usr/

Each project's Makefile will assume the following variables:

  $(usr)      -- points to the stuff that's currently in
                 upstream/install

  $(build)    -- build directory [we need to discuss this]

You'll set these in your Makefile, but if your project is being used
as a "subproject" (ie the way core uses js), it will override the
usr and build variables.

I'd also like to try to standardize the top-level directory layout for
projects like this:

   Makefile
   README
   src/
   web/   (more on this later)
   doc/
       AUTHORS
       COPYING
       ...

Ideally there should be only five things in the top level directory
(Makefile, README, src, web, and doc).  When you build a project, it
first checks to see if $(usr) is set.  If not, it fetches the usr repo
and puts it in the top level directory (ie a peer of src) and points
$(usr) at it.  Henceforth, whenever any subpackages are built, they
all share a common $(usr).

The usr "project" should look something like this:

  usr/
      make/
           Makefile.gcc
           Makefile.binutils
           Makefile.mips2java

And so forth.  The Makefiles have the required patches *built in*
(using <<EOF).  In general I think we can trim down the amount of
patching we're doing.
               
This way you can build something like org.ibex.mips2java standalone,
or as a "usr" package of the core.  But they'll share a common
$(usr)/src/gcc/ source download.

I'd like to avoid the .configure_* / .download_* / .install_* stuff
(and the corresponding mips2java tasks/*) -- I think we can depend
directly on the results of each step, eliminating the possibility of
getting out of sync.

Anyways, back to the repositories.  The cool part is that each
..www.. directory *is* the darcs repo!

  /var/www/org/ibex/js/
                       _darcs/
                       web/
                       src/
                       doc/
                       README
                       Makefile
                       
The "document root" for the web server is the web/ directory.  The
wiki will actually modify files directly in the repo and then 'darcs
record' the changes.  In fact, the whole web/ directory is actually a
wiki, but most parts aren't globally editable.  I can play a cool
trick to map the "entire darcs space" to either:

   repo.project.ibex.org

Or else

   project.ibex.org/repo/

Or even

   repo.ibex.org/project/

So you can do checkouts.  I'm not sure which yet.  I like the
impression of autonomy you get from the first two.

Should web be a subdirectory of doc?  Probably...

This is one point I'm not completely happy with; I'd prefer to have a
single darcs repo for each project.  I'm actually thinking it might be
better to give each developer his/her own "$USERID.users.ibex.org"
(and the ability to make subdomains thereof).  If you want to test a
new website layout, you just push it to one of your personal
subdomains.  BTW, I have a badass DNS provider that lets me automate
adding new DNS records, so this will be easy.

Lastly, although darcs' commit-via-patches thing is ubercool, I think
the overhead of getting PGP working as well as having to maintain a
duplicate set of ssh/pgp keys is just too much of a pain.  So,
henceforth, once you get approval, just 'push --and-apply' via ssh.

Which brings me to mailing lists.  I'd like to further streamline the
whole system by having exactly one mailing list per subproject.  I
think it's okay for people to post patches directly to the core list;
we'll still use the approval/commit-your-own procedure.  Widgets has
its own subproject, so it implicitly has its own mailing list.  Same
with mips2java.

I think the only problem remaining is that there's no separation
between the core list and the newbies list.  But nobody really uses
the newbie list anyways.  I'm wondering if it's really such a big deal
to mix the two lists.  People never respect the "don't post stupid
questions to the dev list" anyways.  Heck, even *I* don't obey that
rule.  And both gcc and linux (much huger projects than us) seem to
get along fine without this sort of segregation.

I think this setup will turn out to be pretty cool.  It'll make it
very easy to spawn subprojects, and really position ibex more like the
apache foundation than a single project.  It's a big step forward.

Anyways, let's talk about this at HHH.

BTW, the one other thing I'm not 100% happy with is having disjoint
source trees.... the whole point of segmenting the namespace into
org.ibex.foo is so that we can union all the source code from all the
subprojects... I guess the nightly javadoc/javasrc generator will do
this, though...

Oh yeah, one more thing.  People might not be happy about this, but
I'd like to use jsp to limit all html documents to valid XML using a
very restricted set of tags (mostly equivalent to guidexml or wiki).
Styling will be site-wide, possibly with some color-scheme variations
to distinguish the subprojects.  I guess it's sort of a branding
thing.
      
  - a                       
     
-- 
"It's lucky," he added, after a pause, "that there are such a lot of
islands in the world.  I almost envy you, Mr. Watson."

                                                   -- Mustapha Mond