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)
