Re: [README] Sawfish 2.90 branched

Am Sat, 30 Oct 2010 13:45:04 +0900 (JST)
schrieb Teika Kazura <teika lavabit com>:

> 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.)

Once I'll find some time, I remember this.

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

OK. I know what you mean. That would be 2.90 almost equal 1.7x, with only a handful
of differences. Perhaps it's better the other way round? so here's another proposal: Keep
1.7 as is, develop in 2.90. 1.8 will the be counterpart of 2.90 but with 20% less suck
(say: all incompatible changes which would require the user to lay hands on the
configuration dropped).


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