[Xmonad] darcs patch: make square work with new doLayout. (and 3
Donald Bruce Stewart
dons at cse.unsw.edu.au
Wed Jun 13 01:37:08 EDT 2007
> 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
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
And if you write a good extension, you get famous ;-)
More information about the Xmonad