Re: [README] Sawfish 2.90 branched



Quotations come from:
On Tue, 26 Oct 2010 17:55:23 +0200, Christopher Roy Bratusek
On Tue, 26 Oct 2010 21:13:47 +0200, Christopher Roy Bratusek

(Don't send twice a day on the same topic. ;)

> Sawfish 3.0 is not just 1.7 + GTK+3. [...]
> more things planned: keyboard stuff, GTK+3, tab-system improvement,
> edges, or check ProposedGoals and BugZilla (…).
> [...]
> Maybe [is] will be released next summer, next winter or in 2012. 2.90.x releases will be
> done meanwhile. I know that this doesn't sound good.

We're random at picking up next tasks; It's a dream, not a plan. wT_Tw
(We've talked a lot on tab, but little has been done after its
adoption.) If all are included, it never comes in 2011.

Ok, my assumption Gtk3 = Sawfish-3 was too assertive. But since we
can't make a clear roadmap, we have to make releases when each good
feature comes ready or on a (roughly) regular basis. The latter has
been, and I think is, good for us.

> Besides there won't be a 1.8x -- 1.7x is supported until at least 3.0

"Supported" sounds bug-fix only, but we keep to develop on the HEAD
(1.7), right? I think it should be so, since "3.0" release seems
far. (It's sensible to go bug-fix only after 3.0 release.)

> [Branch 2.90] introduces incompatible changes (more than just module
> renaming), which are to be avoided in the stable branch.
> [...]
> Fixes of course go into both [HEAD and 2.90], for the new
> quote-event it depends on whether it introduces incompatibilities.

Ok, so you want test new, experimental features in 2.90 series
release. It's reasonable. But there ARE also changes incompatible but
easy, stable, and really nice. To profit users, they should be
released sooner. Then comes 1.8.0. (And maybe 1.9.0 and so on); bump
to 1.8, not 1.7.x to indicate a moderately "big" change, here
incompatibilities. There's no reason to stick to 1.7.x. (Does
"Religion 1.7" rule Sawfish?)

Jump-to-exec may be a blocker until refined (let's ensure it before a
release, by recording in Wiki. I haven't checked the latest, though.),
but it surely can be done in the HEAD. Furthermore, this advocates
topic branches. Doing all in 2.90 obfuscates the status.

I'm going to tailor my commits for the HEAD. I will never write
news.texi and ChangeLog for both! (They always cause merge conflicts.)


Now let's distinguish well the 2.90 release and the git branch, and
consider first the difficulty of 2.90 branch. It's really cumbersome
to push commits to both 1.7 and 2.90, so the strategy will be not to
touch 2.90 except experiments, and when a release comes close, merge
the HEAD (= 1.7). But this merge is big and it'll be difficult to make
it hold water.

I propose this. Use topic branch for each "topic". When one is almost
done, merge it into the HEAD, regardless of being incompatible or not,
and dispose of the topic branch. This merge is smaller, so easier to
handle, and surer of the quality.

When we want to release 2.90, and we still have topic branches that
we hesitate to merge to the HEAD, although we believe it's not that bad,
then depart for the first time from the HEAD to prepare branch-2.90.
Merge topic branches to branch-2.90, and let it go.

If we think topic branch A is in good state, and announce so, then
user can try HEAD + A if they like. User can be at ease, rather than
trying obscure current 2.90.

(In fact, for most cases even topic branch is not necessary. Simply
push almost ok changes to the Gnome repo, and it's done. For us, a
topic branch is only necessary when you want to share the code to ask
a help.)

> I would prefer a long-time-taking 3.0 which is high-quality in both new features,
> bugfixes and stability

It's nice, but let me raise one more. Releases 2.90 (or 2.90.x) and
2.91 sound "almost the same", so 2.91 may not attract much attention.
We have to live with our situation where the community is not so big.

This is another reason that merges to HEAD is better, likelier to
be tested by more people.

Anyway we've been largely not bad. Let's be confident. :)

> I'm currently reading docs about Scheme/LISP
Great. (I wonder if you could write "a librep crash course for scheme
users." The elisp version was based on my experience - what was
difficult, confusing, or what remained ambiguous long.)

Thank you for reading. Regards,
Teika (Teika kazura)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]