Re: Release process, syncing with Emacs

[Kai Grossjohann]

Michael Albinus <address@hidden> writes:

> Kai Grossjohann <address@hidden> 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