emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Choosing a moment for the Bazaar switchover.


From: Karl Fogel
Subject: Re: Choosing a moment for the Bazaar switchover.
Date: Fri, 20 Mar 2009 17:16:23 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Stefan Monnier <address@hidden> writes:
>> Thanks to Jason Earl and others, we've solved most of our Bazaar
>> conversion issues.
>
> Can we have a quick description of the state of the conversion business?
> IIUC we now have a conversion that preserves the history, branches, and
> tags from the CVS repository, plus adds the merge info coming from the
> Arch (via the git) repository (and half-manually stuffed into the git
> repository, thanks to Andreas), plus adds the rename info
> guessed/inferred by git itself.
>
> And that conversion can be done "easily" but cannot be updated later on
> to incorporate changes in the CVS repository, forcing us into a "flag
> day" scenario.
>
> Right?

Yes, "flag day" is what we're looking at.  

Your description of the conversion sounds right; Jason can respond
authoritatively.

> Also, what's the status of the Savannah hosting?  Looking at
> http://savannah.gnu.org/support/index.php?106612, it's not clear whether
> "bzr+ssh" access is available, and whether emacs-commit is working.
> Do we have a test branch setup there?  Anything else that might be
> missing?

All the todo items I know about are listed at
http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover, and I'm happy to
push on them.  We don't have a test branch yet; making one would be part
of that.

(I'm trying to avoid a situation where Sylvain works really hard to get
everything set up, and then it's months before we actually switch, so it
bitrots and some of the work has to be redone.)

>> When should we do this?  Some options:
>
>>    1) Now, i.e., as soon as the conversion is ready (in which case we'll
>>       start prepping knowing that it's for real this time).
>>    2) When we branch for release.
>>    3) Immediately after the release.
>
> I think I'd prefer 2.  It should be a time where the release branch
> (currently "trunk") doesn't see too much activity, which would help.

Do we have a rough idea when (2) is?  (It's probably been talked about
here, but... there's a lot of mail, and there are few on-web clues about
the schedule.)

Thanks,
-Karl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]