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

[Stefan O'Rear]

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.

Stefan