Am Sat, 30 Oct 2010 13:45:04 +0900 (JST) schrieb Teika Kazura <[email protected]>:
> 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). Chris
