multihead and different versions

[William Diem]

I'm planning to do the following shortly:

1) merge the multihead branch into trunk.
2) push a 0.2.rc1 tarball, and remove the 0.2.alpha2 tarball.
3) add basic documentation for multihead to the manpage, but clearly
indicate the multihead is experimental, and that the behavior is
subject to change.

My reasons are

1) When I first branched I wanted to make extensive changes and
experiment, without foobaring mainline. At this point I'm fairly
confident there are no massive regressions introduced in the branch
(meaning it still works fine on a a singlehead setup), so I think I'm
on the right track and nothing is going to get broken beyond repair.
2) When I first branched I didn't anticipate many updates to the
trunk, but there have been a few fairly significant commits, and I
don't want to make the merge harder than it needs to be by letting
them continue to grow apart.
3) If I'm wrong about (1) I want to find out, and svn trunk is the
pace to do it (since it is effectively the mainline development
version), there is a stable version for people who don't want to risk
regressions. Putting them together will streamline testing, rather
than spliting the testing base up.
4) Pushing unfinished and relatively untested multihead support into
trunk doesn't bother me because, trunk doesn't currently support
multihead at all, so even if it is broken or buggy it isn't a
regression (as long as the bugs are only triggered when using multiple
monitors). Also, the documentation will make it clear that the
commands are subject to change, and that this area is
underdevelopment, so people who do use it with multiple monitors will
know not to get too comfortable just yet.

I think that's it.

Just a heads up.

[BKLive]

Since the addition of fullscreen support for flash (and others) was a
big "bug fix" does that constitute a 0.1.2? This would put the
mainline release more compatible with end user expectations (having a
working wm that does fs) and allow for the main version to continue to
not release bugs into the mainline since the multihead support isn't
necessarily tested "to standard" since we're not using multihead boxes
to test. This would keep the multihead branch somewhat "perm-alpha" or
"rc'd" because until that testing criteria is met, there is no
garantee it works, but at the same time it would allow for the major
functionality revision (I consider it major, at least) of propper fs
handling to be exported to the main release.

Just a thought. Updating AUR to reflect svn and 0.1.1 for now.

[William Diem]

On 4 August 2010 12:32, BKLive <benjami...@gmail.com> wrote:
> Since the addition of fullscreen support for flash (and others) was a
> big "bug fix" does that constitute a 0.1.2? This would put the
> mainline release more compatible with end user expectations (having a
> working wm that does fs) and allow for the main version to continue to
> not release bugs into the mainline since the multihead support isn't
> necessarily tested "to standard" since we're not using multihead boxes
> to test.

Considering the fs changes a bugfix would also have been an option,
and releasing a micro release with it while the merged version was in
rc would have been possible.
At the end of the day though I want to get the two branches together,
and I want to get both of them used heavily.
For me the crux of it comes down to the fact the multiscreen has never
worked in stable or trunk, so if multiscreen isn't tested to standard
(on multiscreen boxes that is) and is found to have bugs or just flat
out not be usable, it isn't a regression, It is a new feature, which
is (and will be) clearly marked as experimental, that isn't working.
Think of it as multiscreen is thrown in for free, "as is": If it
works, great, if it doesn't we never said it would (please file a bug
report so we can get it working).
As to whether the multiscreen code introduces regressions (that is,
new bugs that appear even if only a single monitor is in use) I've
been using it almost exclusively for several days with no issues at
all, the tarball has been up for several days with no bug reports, so
I think it is responsible of me to assume that it is ready to go into
the rc stage (not, however, to assume that it is ready to be labeled
stable: there will be an rc first).
The main reason I want to put the multihead into trunk is that I don't
want a monster merge: If it is safe to merge now, I want to get it
done asap (Safe = no regressions). This also means all the issues of
"which development branch?" go away. It also means we will have a
chance to get more people running the fullscreen code (hopefully
during the rc stage).

> This would keep the multihead branch somewhat "perm-alpha" or
> "rc'd" because until that testing criteria is met, there is no
> garantee it works, but at the same time it would allow for the major
> functionality revision (I consider it major, at least) of propper fs
> handling to be exported to the main release.

All my plans have been on the assumption that the multiscreen support
does not introduce bugs for users with one screen. If this is true,
the only hold up that it will introduce in getting fs support into the
current stable release will be the length of the rc stage, which I
plan to make a couple of days, like I said it's been run quite a bit
already.
If we are worried about new users coming while 0.2.0 is in rc, seeing
that 0.1.1 doesn't support fs for some of their apps and walking away,
my thought is that the googlecode main page will have a prominent
announcement at the top introducing 0.2.rc1 and mentioning the new
features, so they will know that better fs is coming in days; Then
they can use the rc if they are impatient and want it now (good for
testing), or if that is too risky, they can check back in a week and
get it once it is labeled stable.

Does this address your concerns, or am I not getting it?

Best,
Will

> Just a thought. Updating AUR to reflect svn and 0.1.1 for now.

Great.

Will