Hi. This is a reply to Chris' previous message. On more plans for 1.5.0: Chris (and all), please separate the thread for distinct issues, or it'll mix up the discussion, making harder to track. (If everyone reads all messages, it's ok, but once or more they skip, it's a mess. Please think of readers.) For private correspondence, it's silly to send 5 messages in parallel, but this is an ML, so it's better to make the title and its content match. What Chris said is important, and deserves a thread.
Christopher Roy Bratusek wrote: > A Doc would be really great. Both a really good dev- and userdoc. and a > tutorial for librep beginners. This is a good idea I can tell, since I > only learned python/gtk by the tutorial - that has been all. So a that > high-quality tutorial for librep is a must-have. This is absolutely true, but what I emphasized in the last post is the *doc for tab*. It's impossible to offer all docs for 1.5.0, but we should do tab docs. I referred to dev & user issue, too, but again you misunderstood what I pointed out. (I think it's important, so could you read my last message again?) > About incompatible changes: Currently there's only one (sawmill-defautls > -> sawfish-defaults).... > And sawfish 1.5.0 _is_ for incompatible > changes, before 3.0 this is the last chance to do so. I meant that adopting tab in hurry will surely result in incompatible changes *after 1.5.0*, in 1.6 or later. > A rewrite of tabs sounds good, but: Nathan Froyd made several changes to > the tab-system and it's his improved version that got in, so perhaps a > rewrite is not necessary? I meant: the criterion is not that it's bug-free or not, but the codes to be released is good enough to allow future extensions. People shall extend it definitely. Rewritement is to reduce incompatible changes which can be avoided. > Either way, who is willing to do [rewritement]? It sounds to me that you fool yourself with such logic into ignoring the issue. It should be decided if it is necessary or not. (I'm not sure for the last point, so I merely satisfied myself by quoting GSR.) If no one does, then the tab gets postponed to become part of the sawfish. It is already available on the web anyway. If recoding is necessary but no one does, I have to do it to avoid cluttered things creap into sawfish. But I'm a slow coder, please be generous to wait for me... I should put it explicitly: we have to set proper goals for the tab, in doc & quality. If they are not met, then tab should be removed from the release to keep the sawfish's quality. > we could do a cat README.IMPORTANT at the end of > configure, or place a good visible (differently colored) message that > users should read that file. ... All we got to do > is to make sure users actually know about that changes. Coloring is good. Output of the configure is a good place, because that's package maintainers watch. Then they'll take care for what's related to their distros. > And sawfish 1.5.0 _is_ for incompatible > changes, before 3.0 this is the last chance to do so. It's better to avoid incompatible changes, but we don't have to assume that 1.5.0 is the last. Regards, Teika kazura
