darcs patch: move Spiral to LayoutHelpers. (and 4 more)
A resend for dons. Conflicts with two recently accepted patches, but I
don't see that as my fault. If you accept patches that implement wrong
fixes for code written my myself that I've properly fixed, then you can
deal with the conflicts.
David
Sat Jun 23 07:35:16 PDT 2007 David Roundy
droundy:
A resend for dons. Conflicts with two recently accepted patches, but I don't see that as my fault. If you accept patches that implement wrong fixes for code written my myself that I've properly fixed, then you can deal with the conflicts.
Thanks David. You can avoid this situatoin by dropping by #xmonad on irc to discuss changes, before sending off mountains of code. Its very hard to review things that haven't been discussed beforehand, which means delays and hold ups, as we sort though the new code. As I say, we like to be cautious. Cheers, Don
On Wed, Jun 27, 2007 at 11:03:58PM +1000, Donald Bruce Stewart wrote:
droundy:
A resend for dons. Conflicts with two recently accepted patches, but I don't see that as my fault. If you accept patches that implement wrong fixes for code written my myself that I've properly fixed, then you can deal with the conflicts.
Thanks David. You can avoid this situatoin by dropping by #xmonad on irc to discuss changes, before sending off mountains of code. Its very hard to review things that haven't been discussed beforehand, which means delays and hold ups, as we sort though the new code. As I say, we like to be cautious.
The trouble is that I have very little time for xmonad stuff. And I generally find that code itself is the best way of expressing an idea as to how to do something. My main objection is not that it took you a while to review the code, but that you applied changes to modules in XMonadContrib for which I am nominally the maintainer without even giving me a chance to comment on said changes, and this after I'd already sent in a fix for the very same issues. It makes sense to apply bugfixes quickly, but not when there's a fix for the very same code by its maintainer waiting for review. -- David Roundy http://www.darcs.net
droundy:
On Wed, Jun 27, 2007 at 11:03:58PM +1000, Donald Bruce Stewart wrote:
droundy:
A resend for dons. Conflicts with two recently accepted patches, but I don't see that as my fault. If you accept patches that implement wrong fixes for code written my myself that I've properly fixed, then you can deal with the conflicts.
Thanks David. You can avoid this situatoin by dropping by #xmonad on irc to discuss changes, before sending off mountains of code. Its very hard to review things that haven't been discussed beforehand, which means delays and hold ups, as we sort though the new code. As I say, we like to be cautious.
The trouble is that I have very little time for xmonad stuff. And I generally find that code itself is the best way of expressing an idea as to how to do something.
My main objection is not that it took you a while to review the code, but that you applied changes to modules in XMonadContrib for which I am nominally the maintainer without even giving me a chance to comment on said changes, and this after I'd already sent in a fix for the very same issues. It makes sense to apply bugfixes quickly, but not when there's a fix for the very same code by its maintainer waiting for review.
Yes, I agree that's the problem. Code is coming in from 2 or 3 people simultaneously touching the same file, so if a large patch is waiting, the easy patches get applied first -- that was the mistake here. In future, we'll have to resolve in favour of the large/maintainer patches first, before proceeding with smaller patches that can conflict with the large ones. And I think it might also be a good idea to claim stronger ownership for contrib modules, so David becomes the go-to guy, if you want to touch, say, Tabbed.hs. Anyway, I've applied your changes to the doLayout stuff, and recommend checking the merge of Tabbed.hs. -- Don
Donald Bruce Stewart wrote:
droundy:
On Wed, Jun 27, 2007 at 11:03:58PM +1000, Donald Bruce Stewart wrote:
droundy:
A resend for dons. Conflicts with two recently accepted patches, but I don't see that as my fault. If you accept patches that implement wrong fixes for code written my myself that I've properly fixed, then you can deal with the conflicts. Thanks David. You can avoid this situatoin by dropping by #xmonad on irc to discuss changes, before sending off mountains of code. Its very hard to review things that haven't been discussed beforehand, which means delays and hold ups, as we sort though the new code. As I say, we like to be cautious. The trouble is that I have very little time for xmonad stuff. And I generally find that code itself is the best way of expressing an idea as to how to do something.
My main objection is not that it took you a while to review the code, but that you applied changes to modules in XMonadContrib for which I am nominally the maintainer without even giving me a chance to comment on said changes, and this after I'd already sent in a fix for the very same issues. It makes sense to apply bugfixes quickly, but not when there's a fix for the very same code by its maintainer waiting for review.
Yes, I agree that's the problem. Code is coming in from 2 or 3 people simultaneously touching the same file, so if a large patch is waiting, the easy patches get applied first -- that was the mistake here.
In future, we'll have to resolve in favour of the large/maintainer patches first, before proceeding with smaller patches that can conflict with the large ones.
And I think it might also be a good idea to claim stronger ownership for contrib modules, so David becomes the go-to guy, if you want to touch, say, Tabbed.hs.
This is probably the next step for using the distributed model in a more public way, but here's what I've seen other projects do when using git, hg etc: Key, or core devs publish their own outgoing trees alongside your own at some location (an example of what I mean is evident here : http://www.selenic.com/mercurial/wiki/index.cgi/DeveloperRepos This means that people like David (Roundy, not me ;-) ) can publish their own tree containing the stuff they are responsible for, and also directly manage the patches for their own code. Then the release team (yourself and Spencer ?) can pull from their published repo whenever you want to, merge it all together into a single release repo, and cut a tag for it. Not sure if this works with darcs since I've never used it (personally, I'm a git ;-) ). But it would solve the problem of people being able to publicly maintain their own code, without you having to worry about the current patch management problem you have - you just have to trust the maintainers. Cheers D
On Thu, Jun 28, 2007 at 12:48:58PM +1000, Dave Harrison wrote:
Key, or core devs publish their own outgoing trees alongside your own at some location (an example of what I mean is evident here : http://www.selenic.com/mercurial/wiki/index.cgi/DeveloperRepos
This means that people like David (Roundy, not me ;-) ) can publish their own tree containing the stuff they are responsible for, and also directly manage the patches for their own code. Then the release team (yourself and Spencer ?) can pull from their published repo whenever you want to, merge it all together into a single release repo, and cut a tag for it.
Not sure if this works with darcs since I've never used it (personally, I'm a git ;-) ). But it would solve the problem of people being able to publicly maintain their own code, without you having to worry about the current patch management problem you have - you just have to trust the maintainers.
That'd work fine with darcs, but seems like overkill for this stuff. Most of the time what I have doesn't differ from main xmonad (except in private changes). -- David Roundy http://www.darcs.net
David Roundy wrote:
On Thu, Jun 28, 2007 at 12:48:58PM +1000, Dave Harrison wrote:
Key, or core devs publish their own outgoing trees alongside your own at some location (an example of what I mean is evident here : http://www.selenic.com/mercurial/wiki/index.cgi/DeveloperRepos
This means that people like David (Roundy, not me ;-) ) can publish their own tree containing the stuff they are responsible for, and also directly manage the patches for their own code. Then the release team (yourself and Spencer ?) can pull from their published repo whenever you want to, merge it all together into a single release repo, and cut a tag for it.
Not sure if this works with darcs since I've never used it (personally, I'm a git ;-) ). But it would solve the problem of people being able to publicly maintain their own code, without you having to worry about the current patch management problem you have - you just have to trust the maintainers.
That'd work fine with darcs, but seems like overkill for this stuff. Most of the time what I have doesn't differ from main xmonad (except in private changes).
I wasn't really thinking in terms of you differing from what's in the release repo, just that you could take ownership of patches to your own contrib modules. This way if someone wants to submit a patch they can just submit it directly to the author / maintainer of the code, instead of having to go the long way round via the core maintainers. It seems to me, that some of these contrib modules (Tabbed especially) have functionality that alot of people might want. So instead of increasing the workload for the core maintainers by having them vet each module patch with its author, the module authors can just accept the patches themselves. They can then feed releases of their module back into the release repo. Dave
droundy:
A resend for dons. Conflicts with two recently accepted patches, but I don't see that as my fault. If you accept patches that implement wrong fixes for code written my myself that I've properly fixed, then you can deal with the conflicts.
I see why you're grumpy ;) This is an annoying merge. Spencer's looking into it. -- Don
On Thu, Jun 28, 2007 at 12:32:58PM +1000, Donald Bruce Stewart wrote:
droundy:
A resend for dons. Conflicts with two recently accepted patches, but I don't see that as my fault. If you accept patches that implement wrong fixes for code written my myself that I've properly fixed, then you can deal with the conflicts.
I see why you're grumpy ;) This is an annoying merge. Spencer's looking into it.
Indeed. And alas, I've got a grant proposal due in less than 36 hours... actually it's not due then, but that's when I leave for New York to get married. So I've got multiple reasons for grumpiness. Under ordinary circumstances, I (hopefully?) would have been able to take things in stride. I've got a week before I'm married, and while I can't say for certain, I tend to rise early, and ion hacking is one of my stress relievers, so there's a chance that some time next week I'll look into this. It's also possible that I'll be so busy spending time with family, preparing for wedding, etc, that I won't touch a computer all week. -- David Roundy http://www.darcs.net
participants (3)
-
Dave Harrison -
David Roundy -
dons＠cse.unsw.edu.au