On Tue, Jun 12, 2007 at 11:41:54PM +1000, Donald Bruce Stewart wrote:

droundy:

...

Here's various compilation fixes for modules that I use (and wrote).

Applied.

sorry guys, I'm the last arrived here and I do not want to sound like the one who starts teaching how to do software development (I can only learn from you). btw, this patches require a patch to StackSet.hs that was not even sent and, at the time, not committed (StackSet.differentiate, for Combo.hs, at least). I'd suggest some form of auditing, just to be sure that precedences and prerequisites are being taken into account. I'm suggesting that a double check could avoid this sort of things, and avoiding this sort of think would be better for XMonada. As I said, these are just my 2c. cia andrea

On Tue, Jun 12, 2007 at 10:02:17AM -0700, David Roundy wrote:

It's been sent. Presumably it'll be applied soon, or if it's rejected someone will send in a different fix.

...

I'd suggest some form of auditing, just to be sure that precedences and prerequisites are being taken into account. I'm suggesting that a double check could avoid this sort of things, and avoiding this sort of think would be better for XMonada.

This is the trouble with having two separate repositories for such closely linked code. The theory (I believe) is that xmonad itself won't change so rapidly as the contrib modules, but when it *does* change, then synchronized changes need to be made.

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 release, and, without bothering to subscribe to the mailing list, pulls the darcs source. Excited she starts messing with such nice extensions, such as tabs and combos, but xmonad keeps crashing or doesn't even compile because of such obvious coding mistakes - such as using undeclared functions... I have the patch, we all have. But she doesn't know the hard, chaotic and quick work that is being done down here to get a solid but still powerfully extensible WM. By the way, I'm very supportive of your code: I've spent the last few days just reading and chasing it. I'm far from asking to stop. I'm just suggesting some care with the public repos. We could, you could set up an internal tree, I'd be delighted to work to help with checking, debugging and stabilizing it. Stuff could be merged as it stabilizes. Or, going on this way, just double check the coherence of each changeset. ciao andrea

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

The other answer is that by having one repo makes people strive for a higher standard for contrib - perhaps that isn't the end of the world. Also Pugs have been very liberal about letting people add stuff, so as long as you are welcoming and friendly (something I don't think we need to worry about!) I think people should be able to freely send patches to the main repo.

Right, the main issue is that main repo stuff needs to be audited, which is quite time consuming. There's nearly twice as much code in the contrib library now, as in the core, and we literally don't have the resources to audit it. So it won't be moved into the core.

Once you've moved to having only one repo, perhaps you could augment your tests to ensure that all the contrib modules at least compile when a patch is applied. This will make you think twice about changing

Right, but we can do that anyway, without literally storing the extensions in the core repo, and still ensure 'bare xmonad' is a simple clean, system the core team fully understands.

the API (not a bad thing), and will ensure that code at least always compiles. For Haskell code, the fact that it compiles is probably

True.

enough to have a reasonable degree of faith that it still probably works.

As a side note, my Haskell folder now has more XMonad stuff flowing into it per day than cabal-devel, hugs-bugs, hugs-users, ghc-bugs, ghc-users, ghc-cvs, hugs-cvs, haskell, haskell-cafe, hat, hoogle, generics and a few others!

Very cool. I noticed there were 46 guys on #xmonad today, a new high score. There's 75 guys in #ion though. Some fun stats: mailing list traffic: * xmonad http://gmane.org/plot-rate.php?group=gmane.comp.lang.haskell.xmonad * dwm http://gmane.org/plot-rate.php?group=gmane.comp.window-managers.dwm * wmii http://gmane.org/plot-rate.php?group=gmane.comp.window-managers.wmii * ion http://gmane.org/plot-rate.php?group=gmane.comp.window-managers.ion.general -- Don

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

droundy:

On Tue, Jun 12, 2007 at 10:09:11PM -0700, Stefan O'Rear wrote:

...

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.

Since you quoted me as an example (presumably because I write very buggy code that often needs fixes), I figure I'll point out that of course I'm

No no. You write the big extensions that make us think about how we should best handle extensions :-)

very happy when someone else fixes code that I've written, and am enjoying the free-for-all atmosphere of XMonadContrib. But I agree with dons that specifying the "official" author needn't reduce that.

Ok. Good. -- Don