[Xmonad] darcs patch: make square work with new doLayout. (and 3 more)

[Donald Bruce Stewart]

stefanor:
> On Wed, Jun 13, 2007 at 02:54:43PM +1000, Donald Bruce Stewart wrote:
> > ndmitchell:
> > > Hi
> > > 
> > > >David, please do not read my word as a critique. I'm just thinking
> > > >about the casual user, possibly a member of the haskell community, who
> > > >read about xmonad, its solid design, a project headed for it 0.3
> > > 
> > > I did ask sjanssen about this originally, asking why not have exactly
> > > one repo for contrib and normal stuff. The answer I got back was that
> > > its harder to tell if a patch touches the core section if they are in
> > > one repo. While that is a perfectly sensible answer, perhaps a simple
> > > grep command could be written which checks this property
> > > automatically, and then have an apply-contrib shell script which stops
> > > if any modification is made to the core xmonad.
> > 
> > We really do want to keep contrib stuff in its own repository, since the
> > core team wants to clearly delimit responsibility for that code away
> > from xmonad's core team :-)
> > 
> > So, we try to find a middle ground between:
> >     * dwm-style patches, where people host their own diffs
> >     * full integration of patches we don't have the time to test or verify
> > 
> > The compromise is to provide central hosting, and a single point of
> > access for all these cool extensions, but with the caveat that they're
> > not tested or audited to the level the core is.
> > 
> > Now, currently they're literally unchecked, and since contribs are all
> > fairly loosely decoupled, its generally safe to apply them -- they won't
> > kill xmonad if we apply a contrib extension that doesn't compile.
> > 
> > However, we can go one better pretty cheaply. I'm writing a script that
> > will double check all contrib modules type check, so we'll at least know
> > the modules are in a sane state. That, along with a page i'm preparing
> > stating who is responsible for each contrib module, so we have a person
> > to `blame' or direct queries to, should help keep the quality high, I
> > hope.
> > 
> > So the strategy is:
> >     * continue providing a single, centralised point for extensions
> >     * but add automatic checking to ensure they're type correct
> >     * and public naming of authors, to ensure responsibility is clear
> 
> I'm not so sure that last part is a good thing.  Currently,
> XMonadContrib is a free-for-all with no borders; when David commits
> bogus code, I have no qualms about randomly fixing it, and Spencer will
> apply it just as easily.  I fear specifying responsibility will have the
> unwanted effect of reducing the collaborative maintainance that
> XMonadContrib has seen so far.
> 

Just in terms of the contrib.html page.

Currently there's an ad hoc list of extensoins, some with authors.

I'm proposing to break it up as:


    * Foo Extension
    * Author:
    * Date
    * Synopsis
    * Screenshot

Just to formalise the thing. Check some of the giant php projects that
have a gazillion extensions -- its the only way to remember who did
what.

And if you write a good extension, you get famous ;-)

-- Don