Michael Albinus <[EMAIL PROTECTED]> writes: > Kai Grossjohann <[EMAIL PROTECTED]> writes: > >> Currently, there are a stable branch and the trunk where new >> development happens. I also decided that I would like to keep Emacs >> in sync with the stable branch. (Likewise for XEmacs, where I have >> invested too little, aka zero, work recently.) >> >> I thought that every stable (2.0.x) release of Tramp would be moved >> into Emacs, and every Tramp change from Emacs would be incorporated >> into the trunk and stable branches. >> >> But then it turns out that little patches went into Emacs between >> 2.0.x releases. Not good. Luckily, I only got one reject on the >> last merge. > > I don't see a general problem here. It happened twice because of > problems detected in Emacs pre-release tests since Emacs has been > frozen beginning of May.
So your suggestion is to merge Tramp bugfixes into Emacs CVS right away, without waiting for a new 2.0.x version? I guess that's okay, if we know what is going on. After releasing a new 2.0.x, we could diff the versions in the Emacs repository and the 2.0.x version to see if there are any differences. Ideally, there should be no differences, I guess. > The crucial point is that such changes should go into tramp-stable the > same time, not only into the trunk (I believe it didn't happen for the > tramp-locked patch at least; I cannot check it just now). The only > problem might be stability. But usually, a stable Tramp release should > appear earliest after 1 or 2 weeks of the last change in CVS, in order > to see whether it works. I think that I left out the locking functionality because I thought it's a new feature. Hm. Perhaps more changes should be merged into stable from the trunk. > But there is another prblem: there should be a policy what to do with > bug fixes applied to the trunk. Either to apply it to tramp-stable CVS > in parallel (this didn't happen last time), or to merge such small > fixes from trunk into tramp-stable before releasing a Tramp 2.0.x > (this didn't happen either for Tramp 2.0.42, I believe). The second > policy is still possible, because the trunk is not SO different from > tramp-stable until now; but this will change. So I'm in favor of the > "apply it twice" policy. Yes, bugfixes should be applied to the trunk and then MFT'd right away. (The FreeBSD folks say "current" instead of trunk and use the term MFC -- merge from current.) Maybe more things should be classified bug fixes. ;-) >> The other thing I wanted to talk about was the fact that release >> entries need to be made in the ChangeLog files. But I think those >> ChangeLog entries could be done automatically. Perhaps I can write a >> Makefile target for them. > > Honestly, I'm lost. What's the problem in writing release entries into > ChangeLog? It's boring ;-) The trunk now has a target which makes this less boring. Perhaps laziness is not a virtue after all, despite what Larry is saying. Kai _______________________________________________ Tramp-devel mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/tramp-devel
