Hi list,

On 21 September 2011 21:58, Dave Tapley <dukedave@gmail.com> wrote:
Hi -devel,

As I've alluded to before I have a fairly large number of local
patches (mostly gtk/2.9 fixes) in my local darcs repo.
I think it makes sense to get these on to code.haskell.org at some point.
The good news is I've been fairly meticulous in ensuring each patch is
encapsulated and has a reasonable commit message, the bad news is that
I've only been testing with wx-2.9.2 and GTK, so my patches will
probably break other configurations.
Firstly, is it worth us setting up an approval queue of some form,
ideally with people on a few different configurations?
Secondly, who has write access for http://code.haskell.org/wxhaskell/ ?

At least Eric, Shelarcy and I, probably a few others. If you have an account on code.haskell.org it is trivial to add you as a committer.

I would suggest that we perhaps set up a wxWidgets > 2.9 repo on darcsden or patch-tag (with caveat that I had a lot of trouble getting my Windows box to talk to darcsden - perhaps I should revisit this).

The new patches go into the development repo with a lightweight review process (the bar for submission should be that one of the group of committers has compiled and tested on at least one target). We could perhaps have occasional (e.g. bi-weekly) freezes where we stabilize existing code on all platforms before moving on.

For the new codebase we explicitly disallow support for older wxWidgets, to get rid of non target-related conditional compilation. We also allow API changes, since a few places we have retained older APIs calling the replacement functions. This is tricky for users of wxcore as they can't look up the function in the wxWidgets documentation, and most wxcore documentation is very sparse (just type info).

We should have another person (I suggest me for this one) who looks at the patches on the new version and back-ports those which are relevant to older wxHaskell versions to the code.haskell.org repo - in other words, older wxHaskell goes into a pure maintenance mode with no new features.

How does this approach sound? We currently suffer because development essentially takes place on the mainline, so large changes destabilize code which we depend on to make releases. I would like to address this.

Best regards