On 22 September 2011 09:54, Jeremy O'Donoghue <jeremy.odonog...@gmail.com> wrote: > Hi list, > > On 21 September 2011 21:58, Dave Tapley <duked...@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'm not on code.haskell.org at the moment, but I'll look in to it. > > 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). I'm fully in support of this. I'll be happy to test on Linux/GTK2, I could test Windows as well, but I don't have any development environment set up, so it might be easier for someone else to do it. I'd also like to put myself forward to write some kind of automated functional test suite. Right now I'm thinking of something as simple as a script to compile everything below ./samples and then execute and terminate each one in turn; perhaps parsing stdout/stderr/exit-codes and printing out a report. That should allow people to quickly identify problems on their platform when we have a code freeze. Dave, > > 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. That's good of you to suggest yourself for that. It might be interesting to see how many people we have actually using wxHaskell from cabal (I wonder if hackage can tell us how many pulls it has per month?), to decide how much effort goes in to backports. > > 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. +1 from myself. Dave, > > Best regards > Jeremy > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
