[xmonad] Darcs advice needed

[Spencer Janssen]

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

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.
   
>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.

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