mainSavannah Administration - Support: sr #106612, Preparation for switching Emacs...

 
 

sr #106612: Preparation for switching Emacs from CVS to bzr on Savannah.

Submitter:  Karl Fogel <kfogel>
Submitted:  Fri 23 Jan 2009 04:57:55 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 13 Aug 2011 02:59:23 PM UTC, comment #28: 

Closing issue.

Michael J. Flickinger <mjflick>
Sat 02 Jan 2010 07:35:49 PM UTC, comment #27: 

This can be closed.  Emacs has migrated to Bazaar, and remaining issues have their own tickets opened.

Karl Fogel <kfogel>
Wed 29 Jul 2009 04:36:08 PM UTC, comment #26: 

I would mark this ticket as being dependent on new ticket https://savannah.gnu.org/support/index.php?106951 (about upgrading Bazaar on savannah to 1.17), but I don't see how to add the dependency.  So, I'm posting this comment instead.

Karl Fogel <kfogel>
Fri 20 Mar 2009 09:01:48 PM UTC, comment #25: 


> I'd like to know the status of the 'emacs' branch that the
> GNU Arch service has been "abused" into hosting.
> (http://arch.savannah.gnu.org/archives/emacs/bzr/)


Regarding this, it is not used any more.  We used it temporarily for the Emacs.app branch, but it's been integrated into the CVS trunk a while ago.

Stefan Monnier <monnier>
Tue 10 Feb 2009 08:32:27 PM UTC, comment #24: 

Thanks, Sylvain!  (As noted in bug #106632, it works for me when I test now too.)

Karl Fogel <kfogel>
Tue 10 Feb 2009 07:56:48 PM UTC, comment #23: 

Looks like it works now, after upgrading a few base python libraries (still with full host+port urls though :))

Sylvain Beucler <Beuc>
Sat 07 Feb 2009 07:58:31 PM UTC, comment #22: 

Oh, looks like you're the one who noticed the duplication, so you're already aware of the code tweak!  Sorry.

-Karl

Karl Fogel <kfogel>
Sat 07 Feb 2009 07:43:27 PM UTC, comment #21: 

Sylvain,

A fix is proposed in https://bugs.edge.launchpad.net/bzr/+bug/305995/comments/2 -- can you try it and see if it solves the problem on Savannah?

(It turns out that the bug I filed, https://bugs.edge.launchpad.net/loggerhead/+bug/325505/, is a duplicate of that.  The automated duplicate catcher didn't match them, because the summaries were written so differently.)

Karl Fogel <kfogel>
Wed 04 Feb 2009 10:16:10 PM UTC, comment #20: 

In https://bugs.edge.launchpad.net/loggerhead/+bug/325505/comments/1 , Michael Hudson asks:

Questions that spring to mind:

1) how are you starting loggerhead?
2) is paste.deploy installed? if so, what version?

Karl Fogel <kfogel>
Wed 04 Feb 2009 09:58:46 PM UTC, comment #19: 
Karl Fogel <kfogel>
Thu 29 Jan 2009 06:48:45 PM UTC, comment #18: 

Hmmm, it seems loggerhead trying to build complete URLs with host and port information while it's supposed to run behing Apache mod_proxy:
  <Location "/lh/">
    ProxyPass http://127.0.0.1:8080/
    ProxyPassReverse http://127.0.0.1:8080/
  </Location>

I don't remember seeing this before so it's probably a new bug in the latest v1.10.

Do you think you can report a bug?
http://launchpad.net/loggerhead

Sylvain Beucler <Beuc>
Thu 29 Jan 2009 05:27:35 PM UTC, comment #17: 

Thanks!

I clicked on the 'gnash' link at lh/, and then on 'libsound' in the directory list that came up, but 'libsound' got me this error:

   "Firefox can't establish a connection to the server at bzr.savannah.gnu.org:8080"

(It looks like any of the other paths in that directory would have gotten the same error.)  The actual URL was:

http://bzr.savannah.gnu.org:8080/lh/gnash/files/head:/libsound/

-Karl

Karl Fogel <kfogel>
Thu 29 Jan 2009 08:33:56 AM UTC, comment #16: 

Ok, thanks for the link.

For the loggerhead task: I updated it a few days ago and wrote a proper init script (dev team cc'd).

You can check this:
http://bzr.savannah.gnu.org/lh/

Sylvain Beucler <Beuc>
Wed 28 Jan 2009 09:25:42 PM UTC, comment #15: 

General switchover checklist started:

   http://www.red-bean.com/scriki/index.php/EmacsBzrSwitchover

Sylvain, you don't really need to pay attention to that page, I'm just including it for reference.  Items that are relevant to Savannah I'll flag over here.

Karl Fogel <kfogel>
Wed 28 Jan 2009 08:48:58 PM UTC, comment #14: 

To be more specific: I didn't actually know, until now, that Savannah was volunteer-run.

Karl Fogel <kfogel>
Wed 28 Jan 2009 08:47:54 PM UTC, comment #13: 

Ah, that clarifies things, okay.

I'm currently making a list of all the things we (Emacs) need to do for the switchover.  I'll make sure to list here anything that involves Savannah, and if any of them look problematic, we can figure out what to do then.

Thanks for the time you're putting into this!  (Remember, I don't know what's "edgy" and what's not -- my expertise is more in Emacs than in Savannah.)

Karl Fogel <kfogel>
Wed 28 Jan 2009 08:23:35 PM UTC, comment #12: 

Btw, mentioning Alioth this way isn't very pleasing as you can imagine. FYI they are not running smartserver and are also running 1.5.

To answer your "more broadly" question: you cannot assume that the Savannah Hackers, which are volunteers, and more particularly myself as I'm usually working on the VCS part of the system, will suddently reprioritize their tasks and free time to work on edgy stuff. There's no magic.
I'm willing to progress on this task though.
Naturally if somebody volunteers to maintain the bzr setup at Savannah this can speed things up.

Sylvain Beucler <Beuc>
Wed 28 Jan 2009 08:23:07 PM UTC, comment #11: 

The thread you pointed starts with "When I run a 'bzr pull' on Emacs repo daily, it is running for >15 mins versus less than 3 mins for git." - so this looks like mentioning a local bzr mirror and a comparison with git, hence my question about it. I appreciate not to dive in the thread, but it's also good to read some parts so as to clarify my understanding of the problem :)

Sylvain Beucler <Beuc>
Wed 28 Jan 2009 08:22:35 PM UTC, comment #10: 

OK, so we have server-side commit notifications since last month.
Things are improving.

The inotify support needs a daemon per project afaik, this isn't scalable.

Using the latest version of bzr with a ssh + smart server access requires a change in the current installation and a migration of existing bzr projects. This looks like the way to go in the long run but this will take more time than using the existing infrastructure.

Sylvain Beucler <Beuc>
Tue 27 Jan 2009 11:16:00 PM UTC, comment #9: 

In this context, "non-commit notification" is what we want (I think): it means notification on pushes to the master branch and any other branches we decide we should care about for commit-email purposes.

This is all with bzr-email installed on the server (master) side, of course.

Karl Fogel <kfogel>
Tue 27 Jan 2009 11:07:29 PM UTC, comment #8: 

http://bazaar.launchpad.net/~bzr/bzr-email/trunk/revision/39 was the commit that adds non-commit notification to bzr-email. This requires:
 - the use of bzr+ssh to push
 - bzr 1.6 or newer (I recommend 1.11 naturally)

Alternatively, the bzr-hookless project provide an asynchronous email-sending facility, which is used by several projects. A dev on that project recently added inotify support to allow it to run in an event triggered fashion. I'll post here with more detail if that is interesting.

Robert Collins <robertc>
Sat 24 Jan 2009 06:21:46 PM UTC, comment #7: 

The reason to prefer more recent bzr is more for performance than feature reasons.

As for the hook (trigger): I may have pointed you to the wrong thing, sorry.  Let me ask around for the Right Way to do server-side commit emails.  The goal here is to have an email go out to emacs-commits@ / emacs-diffs@ when a change lands in a branch that everyone cares about -- e.g., trunk.

It does have to be server-side: we can't require that every developer have outgoing email configured on their development machine, and we'd want centralized control of the format and destination of those emails anyway.

Karl Fogel <kfogel>
Sat 24 Jan 2009 05:17:46 PM UTC, comment #6: 

This looks like a client commit hook (not a server commit hook) - I mean, something that every Emacs dev install on his/her desktop.
In addition it doesn't seem to require a recent version of bzr.

Am I wrong?

Sylvain Beucler <Beuc>
Sat 24 Jan 2009 04:55:23 PM UTC, comment #5: 

https://edge.launchpad.net/bzr-email/

To actually fetch it, this works:

   $ bzr branch lp:bzr-email bzr-email
   $ cd bzr-email
   $ ls
   emailer.py   _init_.py         README
   setup.py     smtp_connection.py  tests/
   $

The README contains further instructions.

Karl Fogel <kfogel>
Sat 24 Jan 2009 04:40:24 PM UTC, comment #4: 


> [smart-server] is necessary to run server-side hooks


Please point me to this server-side hook.

Sylvain Beucler <Beuc>
Sat 24 Jan 2009 03:42:37 PM UTC, comment #3: 

 > The thread you mentioned starts with some kind of bug report (about a CVS->bzr mirror??) and mentions git. Is this serious?

Yes, it's serious.  The thread goes through many twists and turns.  Git is involved in the conversion process from CVS to bzr, but that detail doesn't matter here.

(I don't know what message you saw as the start of the thread; the candidates I see are not bug reports about a CVS->bzr mirror... but don't worry about it.  My job here is to make it unnecessary for you to dive into the thread(s). :-) )

The sftp method is slower than having bzr installed on the server; also, the latter is necessary to run server-side hooks (which we'd want to do for commit emails).  I'm just a bzr user, by the way, not at all an expert.  To find out those things about sftp, I went and asked in #bzr on irc.freenode.net :-). 

(Someone there, more knowledgeable about bzr than I, has volunteered to help you, incidentally.  I don't want to paste his email address into a public bug report, but contact me privately -- kfogel {AT} red-bean.com -- if you'd like his contact info.)

I don't know if anyone is currently using the http://arch.savannah.gnu.org/archives/emacs/bzr/ branch; I don't think we're going to be using it for the "real" conversion, though.

If Savannah is truly stuck on bzr 1.5, then maybe I should go talk to Alioth?

More broadly: I'm not quite clear on the relationship between Savannah and GNU Projects.  The decision to switch to bzr comes ultimately from RMS; does that mean we can assume Savannah will put non-trivial effort into this, or should we not assume that?

(No judgement is implied in the question, by the way; I just want to understand the situation.)

Thanks,
-Karl

Karl Fogel <kfogel>
Sat 24 Jan 2009 12:44:44 PM UTC, comment #2: 

Hi,

> GNU Emacs is getting close to switching from CVS to bzr


The thread you mentioned starts with some kind of bug report (about a CVS->bzr mirror??) and mentions git. Is this serious?


> bzr on Savannah is still in beta?


Yes, the bzr server-side didn't evolve afaik. A clean way to provide bzr support would involve using a restricted shell environment that run the bzr client (like cvs/svn/git/hg do), but so far the preferred way to access bzr is still sftp, and I don't know about maintained server-side hooks that would allow proper on-commit e-mail notifications.

Afaics launchpad and alioth provide bzr through a non-restricted shell environment where people essentially install and configure repos by themselves, an environment where's not planning to offer since it's a different beast to maintain security-wise.

So yes, currently it's in test, which means it's subject to change along with server-side improvements (though it hasn't much).


> bzr 1.11 is now released; is Savannah on that?


I believe you have a good understanding of bzr. Given that bzr works on top of sftp, what's the point in having bzr even installed at Savannah? :)

More to the point, we run the Debian package from backports.org, which is currently frozen at 1.5-1 along with Lenny, so it would be inconvenient to upgrade now - should we need it.


> We're still doing some test conversions, but things are
> looking good so far.


I'd like to know the status of the 'emacs' branch that the GNU Arch service has been "abused" into hosting. (http://arch.savannah.gnu.org/archives/emacs/bzr/)
Is it used?
Can it be removed?


> I think soon we're going to schedule a "flag day" for the
> switchover. Among other things, that will mean the CVS
> repository goes into read-only mode, which is something
> we'll need to coordinate with you.


The best is to write an 'at' job to install the proper CVS commit hook on time. We can do that.


> I just learned from sr #106531 that we don't have a
> Loggerhead installation at Savannah. Can we?


I actually installed it a while ago http://bzr.savannah.gnu.org/lh/ following a Gnash request but apparently it broke and nobody reported it. I wish there were a proper init script (I reported it at the loggerhead project). Anyway we can enable it, but possible close it if this becomes a resources hog.

Sylvain Beucler <Beuc>
Fri 23 Jan 2009 05:42:36 PM UTC, comment #1: 

I just learned from sr #106531 that we don't have a Loggerhead installation at Savannah.  Can we?

Karl Fogel <kfogel>
Fri 23 Jan 2009 04:57:55 PM UTC, original submission:  

GNU Emacs is getting close to switching from CVS to bzr, see <a href="http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00575.html" >this message</a> and the <a href="http://lists.gnu.org/archive/html/emacs-devel/2009-01/threads.html#00575" >thread</a> in which it is embedded for details.  (The thread is huge, though, and there's no need for you to read it; I'm happy to relay the important information over here.)

I'm not quite sure what the status of bzr on Savannah is.  On the one hand, there's <a href="https://savannah.gnu.org/support/?106417" >ticket #106417</a>, which implies that bzr on Savannah is still in beta?  On the other hand, bzr is not mentioned at all in the <a href="http://savannah.gnu.org/maintenance/FaQ">FAQ</a>.

bzr 1.11 is now released; is Savannah on that?  If not, can it be?  Is there anything else that would need to be done on the Savannah side for Emacs to switch over?

We're still doing some test conversions, but things are looking good so far.  I think soon we're going to schedule a "flag day" for the switchover.  Among other things, that will mean the CVS repository goes into read-only mode, which is something we'll need to coordinate with you.

Any other issues we should be thinking of?  Or are you basically ready when we are?

Thanks,
-Karl

Karl Fogel <kfogel>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mjflick (Posted a comment)
  • -email is unavailable- added by monnier (Posted a comment)
  • -email is unavailable- added by walles
  • -email is unavailable- added by robertc (Posted a comment)
  • -email is unavailable- added by Beuc (Posted a comment)
  • -email is unavailable- added by kfogel (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-08-13 mjflick Open/ClosedOpen Closed
    2009-02-15 walles Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code