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