Darcs advice needed
Hi there! As I'm preparing to merge Bluetile's repository back into xmonad's mainline, I'm a little unsure how to best use Darcs for this goal. I don't have that much experience with Darcs, so I was hoping, I could get some advice on what is the best way to go about this. So there is the public xmonad repository as well as the public Bluetile repository. Now let's say I have two kinds of features: Some simple ones, like feature X, that can just go in unchanged. But there might also be some feature Y, where I might decide that for submission as a patch, I have to do it in a somewhat different way. So I want to revert Y and code it again as Z. How do I do this? I can think of these ways: 1. Have a new repository based on xmonad's mainline, where I incrementally pull in stuff from Bluetile's repo and polish it up. So in this case, I would pull X, but not pull Y, instead write a new patch for this repo that implements Z. Seems like a simple approach to me, but has the disadvantage, that Bluetile's repo will never get in sync with xmonad's repo, because it still has the X stuff. 2. Work with Bluetile's repo and simply obliterate patch Y and implement patch Z. This seems like a bad approach, as people that might have pulled from Bluetile's repo won't notice that a patch was obliterated. It seems the Darcs manual agrees, that patches should never be obliterated, once they are public. 3. Work with Bluetile's repo and create a reverse patch Y^-1 as well as patch Z. This has the advantage, that Bluetile's repo can get in sync with xmonad's mainline. I'm just not sure, if this is the 'darcs way' of doing things? Also, when submitting patches for feature Z, do I submit a) Y, Y^-1 and Z or b) just Z? Case a) seems like a lot of junk that shouldn't be in xmonad's mainline. But for case b) I fear, it might not be possible for some cases. Let's say the patch history looks something like: Y A B C D E F Y^-1 Z. Then later when working on A or B, it might not be possible to go without Y even so it's later reverted. Comments? Advice? Best regards, Jan
Excerpts from Jan Vornberger's message of Sun Sep 13 20:53:07 +0200 2009:
Hi there!
As I'm preparing to merge Bluetile's repository back into xmonad's mainline, I'm a little unsure how to best use Darcs for this goal. I don't have that much experience with Darcs, so I was hoping, I could get some advice on what is the best way to go about this.
So there is the public xmonad repository as well as the public Bluetile repository.
Now let's say I have two kinds of features: Some simple ones, like feature X, that can just go in unchanged. But there might also be some feature Y, where I might decide that for submission as a patch, I have to do it in a somewhat different way. So I want to revert Y and code it again as Z. How do I do this? I can think of these ways:
1. Have a new repository based on xmonad's mainline, where I incrementally pull in stuff from Bluetile's repo and polish it up. So in this case, I would pull X, but not pull Y, instead write a new patch for this repo that implements Z. Seems like a simple approach to me, but has the disadvantage, that Bluetile's repo will never get in sync with xmonad's repo, because it still has the X stuff.
I think that this is your better option. Which I can rephrase as: * pull as much as possible all the patches that you want to publish unchanged * for each other feature: - minor change (one patch): + pull the patch + polish the code + amend-record it - major change + pull the patches + unrecord them + polish the code + record as one or several patches Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr
On Sun, Sep 13, 2009 at 08:53:07PM +0200, Jan Vornberger wrote:
Hi there!
As I'm preparing to merge Bluetile's repository back into xmonad's mainline, I'm a little unsure how to best use Darcs for this goal. I don't have that much experience with Darcs, so I was hoping, I could get some advice on what is the best way to go about this.
So there is the public xmonad repository as well as the public Bluetile repository.
Now let's say I have two kinds of features: Some simple ones, like feature X, that can just go in unchanged. But there might also be some feature Y, where I might decide that for submission as a patch, I have to do it in a somewhat different way. So I want to revert Y and code it again as Z. How do I do this? I can think of these ways:
1. Have a new repository based on xmonad's mainline, where I incrementally pull in stuff from Bluetile's repo and polish it up. So in this case, I would pull X, but not pull Y, instead write a new patch for this repo that implements Z. Seems like a simple approach to me, but has the disadvantage, that Bluetile's repo will never get in sync with xmonad's repo, because it still has the X stuff.
I think bluetile and xmonad's repos will never be exactly in sync. There are some patches such as the renames to xmonad-bluetilebranch that we'd rather not have in xmonad, even if they're inverted. Instead, we should aim to get changes upstream and deprecate the old xmonad-bluetilebranch repo.
2. Work with Bluetile's repo and simply obliterate patch Y and implement patch Z. This seems like a bad approach, as people that might have pulled from Bluetile's repo won't notice that a patch was obliterated. It seems the Darcs manual agrees, that patches should never be obliterated, once they are public.
Usually I'd agree, but if the ultimate plan is to deprecate xmonad-bluetilebranch it is necessary to obliterate a few patches just to avoid conflicts with upstream. However, this should be done in some staging area rather than http://code.haskell.org/bluetile/xmonad/ .
3. Work with Bluetile's repo and create a reverse patch Y^-1 as well as patch Z. This has the advantage, that Bluetile's repo can get in sync with xmonad's mainline. I'm just not sure, if this is the 'darcs way' of doing things? Also, when submitting patches for feature Z, do I submit a) Y, Y^-1 and Z or b) just Z? Case a) seems like a lot of junk that shouldn't be in xmonad's mainline. But for case b) I fear, it might not be possible for some cases. Let's say the patch history looks something like: Y A B C D E F Y^-1 Z. Then later when working on A or B, it might not be possible to go without Y even so it's later reverted.
Comments? Advice?
Best regards,
Jan
From here I'd suggest that you simply create patches in the staging area, leaving the old patches unchanged. Amend-record and re-record strategies destroy project history irrevocably, and should be used only if they make
I just took a look at your repo, and this is how I'd suggest doing things: - create a branch of bluetile that is a staging area for submissions to xmonad - 'darcs obliterate' these patches related only to the development of bluetile: * Changed cabal file to call this package xmonad-bluetilebranch This allows for xmonad and xmonad-bluetilebranch to coexist until the changes are merged with upstream. * Make xmonad-bluetilebranch hidden by default to not clash with xmonad * Prepared code to go on hackage * Resolved conflict with hidden-patch * Change maintainer for this branch - 'darcs pull http://code.haskell.org/xmonad' to make sure that further patches don't conflict with upstream. the revision history very ugly. Follow similar steps for any changes you've made in contrib. This advice is geared towards preparing patches for xmonad so that 'xmonad-bluetilebranch' can be dropped in favor of mainline xmonad. This is the first time I've looked at bluetile, here are some random comments from my first look: - "half-implemented support for replacing an existing window manager". Most likely candidate for inclusion, send this in first, along with any polish you feel it needs. - PositionStore. What is this for? It doesn't seem very used in the core. Can this be a ManageHook instead? Hopefully we can get to a point where bluetile is merely an executable built on mainline xmonad, this will be easiest for you to mantain in the long run, and will help us avoid polluting xmonad's brand with a fork. Cheers, Spencer Janssen
On Mon, Sep 14, 2009 at 11:01:00PM -0500, Spencer Janssen wrote:
I just took a look at your repo, and this is how I'd suggest doing things:
[SNIP]
From here I'd suggest that you simply create patches in the staging area, leaving the old patches unchanged. Amend-record and re-record strategies destroy project history irrevocably, and should be used only if they make the revision history very ugly.
Thx for your suggestions. I think I will do things along those lines. I also agree that I'd rather avoid 'amend-record' or re-recording stuff that is already 'public' - even if it is in a repository, that will eventually be dropped.
This is the first time I've looked at bluetile, here are some random comments from my first look: - "half-implemented support for replacing an existing window manager". Most likely candidate for inclusion, send this in first, along with any polish you feel it needs.
I already posted the current version of the patch a while ago (http://osdir.com/ml/xmonad@haskell.org/2009-05/msg00010.html). Right now it _always_ replaces, which is what I want. If I added a '--replace' flag, I would also need to have a configuration option, to override that (because I feel it's important, that simply starting Bluetile will replace Metacity without requiring any flags or anything). I'll have to see if I get around to implement those improvements.
- PositionStore. What is this for? It doesn't seem very used in the core. Can this be a ManageHook instead?
It's used to store how all the windows look when in traditional 'stacking window layout'. This can't be easily maintained by the layout itself, because windows might shift around from one workspace to another. (To illustrate: I want to be able to do this: Workspace 1 is in 'stacking window layout' and shows a window. The window is then shifted to workspace 2, which currently has a tiling layout active. The window is tiled. Now, when I change the layout to 'stacking window layout' on workspace 2 as well, I want to see the window in it's original form again.) For this I need - as far as I can tell - a global place where I can store these positions and sizes. However I agree, that the PositionStore is probably not something, that should go into xmonad's mainline. An alternative way could be to use Daniel Schoepe's extensible state patch [1]. It seems useful in itself and is a cleaner and more general solution. The PositionStore could than be implemented as a contrib module on top of this extensible state.
Hopefully we can get to a point where bluetile is merely an executable built on mainline xmonad, this will be easiest for you to mantain in the long run, and will help us avoid polluting xmonad's brand with a fork.
I agree, that would be the best solution. Regards, Jan [1] http://article.gmane.org/gmane.comp.lang.haskell.xmonad/8126
participants (3)
-
Jan Vornberger -
Nicolas Pouillard -
Spencer Janssen