
Hi there! I feel a little bit like a child asking "are we there yet?", but it has been four months since I asked this on this list the last time, so it seems reasonable: Can we please release a Bluetile-compatible version of xmonad and xmonad-contrib sometime soon? So that Bluetile no longer depends on unreleased code that prevents it from being packaged? As I said before, I'm happy to help out where I can with any pre-release stuff that needs to be done. Regards! Jan

Jan.Vornberger:
Hi there!
I feel a little bit like a child asking "are we there yet?", but it has been four months since I asked this on this list the last time, so it seems reasonable: Can we please release a Bluetile-compatible version of xmonad and xmonad-contrib sometime soon? So that Bluetile no longer depends on unreleased code that prevents it from being packaged?
Let's do it. I should have time for some QA work next week. Spencer? Everyone else? Any blockers??

Hello, On Wed, May 19, 2010 at 01:48:47PM -0700, Don Stewart wrote:
Spencer? Everyone else? Any blockers??
Doesn't work on FreeBSD and OpenBSD: http://www.haskell.org/pipermail/xmonad/2010-April/010047.html -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

Hi! Additionally the last stable xmonad 0.9.1 didn't work on solaris and I doubt that something in that matter has changed. See here http://www.haskell.org/pipermail/xmonad/2010-January/009669.html Tomáš Janoušek schrieb:
Hello,
On Wed, May 19, 2010 at 01:48:47PM -0700, Don Stewart wrote:
Spencer? Everyone else? Any blockers??
Doesn't work on FreeBSD and OpenBSD: http://www.haskell.org/pipermail/xmonad/2010-April/010047.html

On Wed, May 19, 2010 at 4:48 PM, Don Stewart
Jan.Vornberger:
Hi there!
I feel a little bit like a child asking "are we there yet?", but it has been four months since I asked this on this list the last time, so it seems reasonable: Can we please release a Bluetile-compatible version of xmonad and xmonad-contrib sometime soon? So that Bluetile no longer depends on unreleased code that prevents it from being packaged?
Let's do it. I should have time for some QA work next week.
Spencer? Everyone else? Any blockers??
Besides the BSD issues, I think this is the perfect opportunity to both take care of all outstanding patches and upgrade the 2 repos' formats. I worry that if we don't do them now (during a pre-release period where changes are possible & licensed), then given everybody's decreased interest, they will never get done. -- gwern

On Tue, May 25, 2010 at 02:35:45PM -0400, Gwern Branwen wrote:
Besides the BSD issues, I think this is the perfect opportunity to both take care of all outstanding patches and upgrade the 2 repos' formats.
I agree that the backlog of outstanding patches should be reduced - but how was that handled in previous releases of xmonad? It seems to me, that right before a release is the last time where you would want to apply a considerable number of little-tested patches, isn't it? Isn't the idea to let development happen over a certain amount of time, then wait a little, let things settle and get the assurance that a fair number of users are running xmonad-darcs without problems before releasing it as a new stable version? Well, of course for those patches that are strictly bugfixes with limited scope it would be nice if they could be included in the release. Regards! Jan

On Wed, May 26, 2010 at 12:35 PM, Jan Vornberger
On Tue, May 25, 2010 at 02:35:45PM -0400, Gwern Branwen wrote:
Besides the BSD issues, I think this is the perfect opportunity to both take care of all outstanding patches and upgrade the 2 repos' formats.
I agree that the backlog of outstanding patches should be reduced - but how was that handled in previous releases of xmonad? It seems to me, that right before a release is the last time where you would want to apply a considerable number of little-tested patches, isn't it?
In previous releases, it wasn't so much of an issue because development was more active. If a patch didn't get decided on in time for one release, well, it would shortly and the next release was only a few months away anyway. (0.1-0.5 were all released in 2007.)
Isn't the idea to let development happen over a certain amount of time, then wait a little, let things settle and get the assurance that a fair number of users are running xmonad-darcs without problems before releasing it as a new stable version?
Well, of course for those patches that are strictly bugfixes with limited scope it would be nice if they could be included in the release.
Regards! Jan
Pragmatism may suggest adding them. Clearly the review is not happening now. If the review of patches has not happened in the last year or so that some of those patches have been outstanding, another year doesn't seem likely to do any good. I hear the Linux kernel folks sometimes add experimental patches to releases because otherwise the patches would never get a thorough testing. Easier to ask forgiveness than permission, etc. And I'm not kidding about the delays. The time span between each release increases significantly. I don't have my original calculation of duration handy, but 0.8 was released September 2008, and 0.9 was released October 2009; assuming that 1.0 is released this year, then that means we've been doing annual releases. And this is even under the psychological pressure of being 0.x releases driving for 1.0. -- gwern
participants (5)
-
Don Stewart
-
Gwern Branwen
-
Jan Vornberger
-
Stephan Schulz
-
Tomáš Janoušek