Re: [Openstack] Moving code hosting to GitHub

[andi abes]

I'm not sure who wins in git vs. bzr ease of use... guess it depends on how
quickly I get over this error:

$ bzr pull lp:swift/1.3
bzr: ERROR: Cannot lock LockDir(
http://bazaar.launchpad.net/~swift/swift/omega-1.3.0-7/.bzr/branch/lock):
Transport oper
ation not possible: http does not support mkdir()


any idea ?

On Wed, Apr 27, 2011 at 1:37 PM, Soren Hansen so...@linux2go.dk wrote:

 2011/4/27 Thomas Goirand tho...@goirand.fr:
  On 04/27/2011 11:26 PM, Soren Hansen wrote:
  To get working, yes. To be an expert, no.
 
  bzr lp-login
  (bzr init-repo)
  bzr branch
  (bzr add)
  bzr commit
  bzr push
 
  ..are sufficient to just get started.
  No, I don't agree, it's not enough. See below.


  and that's most of the time the issues with using bzr for git users
  tutorials: they tend to think that you're ok with the most basics
  command, and that you wont ever need more. Truth is you do, and
  finding the relevant information for the thing you need takes time (a
  big cost, to use your own words...).  If you find a learning quickly
  advanced bzr commands for git users type of tutorial, I might change
  my mind! :)
 
  If you can explain what sort of stuff you've had a hard time finding, I
  can probably whip up something that will be helpful to others.
  - git reset --hard sha256

 bzr uncommit -r revisionspec

 that leaves the changes in the working directory, though. You can use
 bzr revert to remove the changes from the working directory.

  - git commit -a --amend (to correct the latest commit)

 bzr uncommit ; bzr commit

  - git format-patch sha256

 bzr log -c revisionspec -p

  - or maybe instead: git diff -u -r sha256 -r sha256

 bzr diff -r revisionspec..revisionspec

  - git push --force (you told me, but I forgot... is that bzr push
  --overwrite?)

 bzr push --overwrite, but please don't use it. It's the same for
 git, really. Once you've pushed it somewhere, don't remove stuff from
 it, or rebase it or whatever. If anyone has pulled from it and based
 work on it, it's extremely awkward if they want to sync up with you.

  - git cherry-pick -x

 bzr merge -c revisionspec, but its use is discouraged.

  - git -r branch (does listing branches on the remote side even make
  sense with bzr?)

 No.

  - git tag (to list tags, as bzr tag tagname seems working)

 bzr tags

  There must be more than I can't recall just now, in 5 minutes of deep
  thoughts.

 I still don't see how any of the above are *required* to start working,
 though.

  Also, one thing I love with git, is that I can always do man
  git-command if I want help with command, and there's more than 100 of
  them. Is this available somehow?

 bzr subcommand -h shows the help for the subcommand.

 bzr help foo is roughly the same, but it provides help for a bunch
 of things other than commands.

 bzr help commands shows you (almost) all the available commands (bzr
 help hidden-commands shows a few extra commands that most people will
 never need)

 bzr help topics shows a bunch of topics that has more extensive
 explanations.


 --
 Soren Hansen| http://linux2go.dk/
 Ubuntu Developer| http://www.ubuntu.com/
 OpenStack Developer | http://www.openstack.org/

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Josh Kearney]

Try 'bzr branch' instead of 'pull'.

On Tue, May 3, 2011 at 5:17 PM, andi abes andi.a...@gmail.com wrote:

 I'm not sure who wins in git vs. bzr ease of use... guess it depends on how
 quickly I get over this error:

 $ bzr pull lp:swift/1.3
 bzr: ERROR: Cannot lock LockDir(
 http://bazaar.launchpad.net/~swift/swift/omega-1.3.0-7/.bzr/branch/lock):
 Transport oper
 ation not possible: http does not support mkdir()


 any idea ?

 On Wed, Apr 27, 2011 at 1:37 PM, Soren Hansen so...@linux2go.dk wrote:

 2011/4/27 Thomas Goirand tho...@goirand.fr:
  On 04/27/2011 11:26 PM, Soren Hansen wrote:
  To get working, yes. To be an expert, no.
 
  bzr lp-login
  (bzr init-repo)
  bzr branch
  (bzr add)
  bzr commit
  bzr push
 
  ..are sufficient to just get started.
  No, I don't agree, it's not enough. See below.


  and that's most of the time the issues with using bzr for git users
  tutorials: they tend to think that you're ok with the most basics
  command, and that you wont ever need more. Truth is you do, and
  finding the relevant information for the thing you need takes time (a
  big cost, to use your own words...).  If you find a learning quickly
  advanced bzr commands for git users type of tutorial, I might change
  my mind! :)
 
  If you can explain what sort of stuff you've had a hard time finding, I
  can probably whip up something that will be helpful to others.
  - git reset --hard sha256

 bzr uncommit -r revisionspec

 that leaves the changes in the working directory, though. You can use
 bzr revert to remove the changes from the working directory.

  - git commit -a --amend (to correct the latest commit)

 bzr uncommit ; bzr commit

  - git format-patch sha256

 bzr log -c revisionspec -p

  - or maybe instead: git diff -u -r sha256 -r sha256

 bzr diff -r revisionspec..revisionspec

  - git push --force (you told me, but I forgot... is that bzr push
  --overwrite?)

 bzr push --overwrite, but please don't use it. It's the same for
 git, really. Once you've pushed it somewhere, don't remove stuff from
 it, or rebase it or whatever. If anyone has pulled from it and based
 work on it, it's extremely awkward if they want to sync up with you.

  - git cherry-pick -x

 bzr merge -c revisionspec, but its use is discouraged.

  - git -r branch (does listing branches on the remote side even make
  sense with bzr?)

 No.

  - git tag (to list tags, as bzr tag tagname seems working)

 bzr tags

  There must be more than I can't recall just now, in 5 minutes of deep
  thoughts.

 I still don't see how any of the above are *required* to start working,
 though.

  Also, one thing I love with git, is that I can always do man
  git-command if I want help with command, and there's more than 100 of
  them. Is this available somehow?

 bzr subcommand -h shows the help for the subcommand.

 bzr help foo is roughly the same, but it provides help for a bunch
 of things other than commands.

 bzr help commands shows you (almost) all the available commands (bzr
 help hidden-commands shows a few extra commands that most people will
 never need)

 bzr help topics shows a bunch of topics that has more extensive
 explanations.


 --
 Soren Hansen| http://linux2go.dk/
 Ubuntu Developer| http://www.ubuntu.com/
 OpenStack Developer | http://www.openstack.org/

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Soren Hansen]

2011/4/26 Thomas Goirand tho...@goirand.fr:
 On 04/27/2011 02:24 AM, Soren Hansen wrote:
 2011/4/26 Thomas Goirand tho...@goirand.fr:
 On 04/26/2011 10:35 PM, Soren Hansen wrote:
 I don't recall seeing anything that makes that a useful nor accurate
 summary. Opinions have been voiced, that's all.
 Re-read then. What you believe are opinions might well be seen by their
 authors as useful and accurate points.
 And you find this to be true only for the people commenting in favour of
 git?
 No. Just commenting on your Opinions have been voiced, that's all,
 which I don't agree with. To me, there's been accurate and useful strong
 points in this thread (on both sides).

Fair enough. My main point was simply that summarising the discussion as
It's much eaiser to try to get your changes merged into a project that
uses git. isn't useful nor accurate.

Both sides have made arguments, voiced opinions, etc. No consensus has
been reached.

 Depends *very* much on the people. If you just sit down and learn the
 3-5 commands needed to get working, the cost is very, very small.
 Knowing 3-5 commands isn't enough,

To get working, yes. To be an expert, no.

bzr lp-login
(bzr init-repo)
bzr branch
(bzr add)
bzr commit
bzr push

..are sufficient to just get started.

 and that's most of the time the issues with using bzr for git users
 tutorials: they tend to think that you're ok with the most basics
 command, and that you wont ever need more. Truth is you do, and
 finding the relevant information for the thing you need takes time (a
 big cost, to use your own words...).  If you find a learning quickly
 advanced bzr commands for git users type of tutorial, I might change
 my mind! :)

If you can explain what sort of stuff you've had a hard time finding, I
can probably whip up something that will be helpful to others.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Thomas Goirand]

On 04/27/2011 11:26 PM, Soren Hansen wrote:
 To get working, yes. To be an expert, no.
 
 bzr lp-login
 (bzr init-repo)
 bzr branch
 (bzr add)
 bzr commit
 bzr push
 
 ..are sufficient to just get started.

No, I don't agree, it's not enough. See below.

 and that's most of the time the issues with using bzr for git users
 tutorials: they tend to think that you're ok with the most basics
 command, and that you wont ever need more. Truth is you do, and
 finding the relevant information for the thing you need takes time (a
 big cost, to use your own words...).  If you find a learning quickly
 advanced bzr commands for git users type of tutorial, I might change
 my mind! :)
 
 If you can explain what sort of stuff you've had a hard time finding, I
 can probably whip up something that will be helpful to others.

Thanks for this.

Just out of my mind... What's the equivalent of:

- git reset --hard sha256
- git commit -a --amend (to correct the latest commit)
- git format-patch sha256
- or maybe instead: git diff -u -r sha256 -r sha256
- git push --force (you told me, but I forgot... is that bzr push
--overwrite?)
- git cherry-pick -x
- git -r branch (does listing branches on the remote side even make
sense with bzr?)
- git tag (to list tags, as bzr tag tagname seems working)

There must be more than I can't recall just now, in 5 minutes of deep
thoughts. Also, one thing I love with git, is that I can always do man
git-command if I want help with command, and there's more than 100 of
them. Is this available somehow? The 2200 lines of bzr.1 aren't much
compared to:
zigo@node3320:/usr/share/man/man1$ find . -iname 'git*' -exec zcat {} \;
| wc -l
46362

It's not that I had hard time finding them, I'm sure they are somewhere
in doc.bazaar.canonical.org. It's more that I would expect to find these
in a quick-start tutorial, when in fact, it seems spread across a huge
doc, which I have no time reading. I'm sure it would help to have at
least the above gathered in a document like:

http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html

which I didn't find very helpful.

Thomas

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Soren Hansen]

2011/4/27 Thomas Goirand tho...@goirand.fr:
 On 04/27/2011 11:26 PM, Soren Hansen wrote:
 To get working, yes. To be an expert, no.

 bzr lp-login
 (bzr init-repo)
 bzr branch
 (bzr add)
 bzr commit
 bzr push

 ..are sufficient to just get started.
 No, I don't agree, it's not enough. See below.


 and that's most of the time the issues with using bzr for git users
 tutorials: they tend to think that you're ok with the most basics
 command, and that you wont ever need more. Truth is you do, and
 finding the relevant information for the thing you need takes time (a
 big cost, to use your own words...).  If you find a learning quickly
 advanced bzr commands for git users type of tutorial, I might change
 my mind! :)

 If you can explain what sort of stuff you've had a hard time finding, I
 can probably whip up something that will be helpful to others.
 - git reset --hard sha256

bzr uncommit -r revisionspec

that leaves the changes in the working directory, though. You can use
bzr revert to remove the changes from the working directory.

 - git commit -a --amend (to correct the latest commit)

bzr uncommit ; bzr commit

 - git format-patch sha256

bzr log -c revisionspec -p

 - or maybe instead: git diff -u -r sha256 -r sha256

bzr diff -r revisionspec..revisionspec

 - git push --force (you told me, but I forgot... is that bzr push
 --overwrite?)

bzr push --overwrite, but please don't use it. It's the same for
git, really. Once you've pushed it somewhere, don't remove stuff from
it, or rebase it or whatever. If anyone has pulled from it and based
work on it, it's extremely awkward if they want to sync up with you.

 - git cherry-pick -x

bzr merge -c revisionspec, but its use is discouraged.

 - git -r branch (does listing branches on the remote side even make
 sense with bzr?)

No.

 - git tag (to list tags, as bzr tag tagname seems working)

bzr tags

 There must be more than I can't recall just now, in 5 minutes of deep
 thoughts.

I still don't see how any of the above are *required* to start working, though.

 Also, one thing I love with git, is that I can always do man
 git-command if I want help with command, and there's more than 100 of
 them. Is this available somehow?

bzr subcommand -h shows the help for the subcommand.

bzr help foo is roughly the same, but it provides help for a bunch
of things other than commands.

bzr help commands shows you (almost) all the available commands (bzr
help hidden-commands shows a few extra commands that most people will
never need)

bzr help topics shows a bunch of topics that has more extensive explanations.


-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[FUJITA Tomonori]

On Fri, 22 Apr 2011 14:52:30 +0200
Soren Hansen so...@linux2go.dk wrote:

 2011/4/22 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp:
 I find the rebasing/cherry-picking practice even worse in the Linux
 kernel context due to the patch tagging used there. If I add a
 Signed-off-by: Soren Hansen to a patch and someone cherry picks that
 patch or moves it around as part of a rebase, my patch still shows up as
 Signed-off-by: me even though I've never signed off on the patch in
 its new context. I remember at one point I had a patch that added some
 Signed-off-by: is not about the context. For Linux kernel, it simply
 says that you release your code under GPL.
 
 Fair enough. That doesn't change that my name is still on the commit,
 and there might be a bunch of Acked-By's or Tested-By's on there that
 suddenly are invalid, because those people never tested the patch in the
 context where it's now found.

git doesn't require you to copy the original Acked-by or
Tested-by. You can't blame git for that. You can misuse any tool.


 You can't control how other people use it.
 
 Of course I can't. I'm objecting to the fact that certain conventions
 among users of certain tools encourage moving patches (not code, but
 patches to code. Very different things.) around and leaving artefacts in
 the metadata that claims that a whole bunch of people have reviewed it
 and acknowledge that it works as intended.

Ditto.


 I vote for git. It's much eaiser to try to get your changes merged
 into a project that uses git.
 
 Can you substantiate that somehow? How is it easier?

Hmm, people already mentioned them. Otherwise, we didn't discuss this
topic. For example, git is much better than bzr about sharing trees
between branches (even you admitted bzr should do better about it).

Why can't we simply use the better tool at this moment?

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Soren Hansen]

2011/4/26 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp:
 Soren Hansen so...@linux2go.dk wrote:
 2011/4/22 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp:
 Fair enough. That doesn't change that my name is still on the commit,
 and there might be a bunch of Acked-By's or Tested-By's on there that
 suddenly are invalid, because those people never tested the patch in the
 context where it's now found.
 git doesn't require you to copy the original Acked-by or
 Tested-by. You can't blame git for that.

If a tool makes a bad thing *very* easy and the right much, much more
difficult, I'd say the tool holds a big part of the blame.

 I vote for git. It's much eaiser to try to get your changes merged
 into a project that uses git.
 Can you substantiate that somehow? How is it easier?
 Hmm, people already mentioned them.

I don't recall seeing anything that makes that a useful nor accurate
summary. Opinions have been voiced, that's all.

 Why can't we simply use the better tool at this moment?

For the sake of the argument, I'll pretend for second that git is a
better tool. What happens when the bzr developers fix the shortcomins
we've identified here, and bzr becomes the better tool, would you
support a switch back to bzr? If not, why not?

You seem to be ignoring the cost of switching. A cost that you're not
going to pay. I, and the other people working on toooling, are going
to have to pay it, so yes, I'm feeling rather attached to a lot of our
existing choices of tools/technology.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Thomas Goirand]

On 04/26/2011 10:35 PM, Soren Hansen wrote:
 I don't recall seeing anything that makes that a useful nor accurate
 summary. Opinions have been voiced, that's all.

Re-read then. What you believe are opinions might well be seen by their
authors as useful and accurate points. I mentioned the fact that
launchpad is really slow to access from China, and sometimes is even
completely inaccessible. That one alone is enough, IMHO. (Please don't
reply again that this will be improved later, or that they are working
on it, too many things share that state, and it just wont happen
tomorrow, and honestly, nobody has a clue on the ETA)

Even if that was only opinions, don't you think they are important too?

 Why can't we simply use the better tool at this moment?
 
 For the sake of the argument, I'll pretend for second that git is a
 better tool. What happens when the bzr developers fix the shortcomins
 we've identified here, and bzr becomes the better tool, would you
 support a switch back to bzr? If not, why not?

One very strong argument is that almost all developers know Git, and not
bzr. That isn't going to change soon.

The introduction of this thread was:

In an effort to speed up our code development processes, reduce the
friction amongst existing contributors and reduce barriers to entry
for new contributors familiar with the popular git DVCS

I believe it still stands.

Now, if we see that there's a really better tool that is available, and
that it seems worth switching (and that makes the cost of switching
worth too), why not? But it would have to improves productivity, and be
widely accepted. Many projects switched from CVS to Git or mercurial,
because it was a big step. I don't see bzr as a big step compared to Git
(and in few cases, it's worse).

 You seem to be ignoring the cost of switching. A cost that you're not
 going to pay. I, and the other people working on toooling, are going
 to have to pay it, so yes, I'm feeling rather attached to a lot of our
 existing choices of tools/technology.

I believe that, in the long run, the cost of learning bzr for each new
comer, is greater than switching the project to Git. Mistakes with the
workflow, like I did when asking you for a review of my patches, are
even greater costs.

On 04/26/2011 10:47 PM, Ed Leafe wrote:
 I, too, prefer git's design, but I also understand the usefulness
 of Launchpad for project management.

There are similar management tools for Git as well. If we don't stick
with GitHub hosting, Gerrit comes to mind...

http://code.google.com/p/gerrit

With Gerrit, we'd keep the code review and centralized thing of
Launchpad, if that is the blocker. But Github has it too (in closed
source), no?

Thomas

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Soren Hansen]

2011/4/26 Thomas Goirand tho...@goirand.fr:
 On 04/26/2011 10:35 PM, Soren Hansen wrote:
 I don't recall seeing anything that makes that a useful nor accurate
 summary. Opinions have been voiced, that's all.
 Re-read then. What you believe are opinions might well be seen by their
 authors as useful and accurate points.

And you find this to be true only for the people commenting in favour of
git?

 I mentioned the fact that launchpad is really slow to access from
 China, and sometimes is even completely inaccessible. That one alone
 is enough, IMHO. (Please don't reply again that this will be improved
 later, or that they are working on it, too many things share that
 state, and it just wont happen tomorrow, and honestly, nobody has a
 clue on the ETA)

 Even if that was only opinions, don't you think they are important too?

Sure, and I'd hope the opposing opinions were equally important.

 Why can't we simply use the better tool at this moment?
 For the sake of the argument, I'll pretend for second that git is a
 better tool. What happens when the bzr developers fix the shortcomins
 we've identified here, and bzr becomes the better tool, would you
 support a switch back to bzr? If not, why not?
 One very strong argument is that almost all developers know Git, and
 not bzr. That isn't going to change soon.

It's very likely that more people know git than there are people who
know bzr, but I wouldn't go anywhere near as far as saying that almost
all developers know git. I'd wager that most developers on this planet
know neither git nor bzr (nor cvs nor svn).

 The introduction of this thread was:

 In an effort to speed up our code development processes, reduce the
 friction amongst existing contributors and reduce barriers to entry
 for new contributors familiar with the popular git DVCS

 I believe it still stands.

It's true. I'm also absolutely fed up with this discussion. I wish
people would just get stuff done instead of arguing over tools.

 Now, if we see that there's a really better tool that is available, and
 that it seems worth switching (and that makes the cost of switching
 worth too), why not?

As Ed points out, whether one or the other is better is contentious, and
that's unlikely to change.

 But it would have to improves productivity, and be widely accepted.
 Many projects switched from CVS to Git or mercurial, because it was a
 big step.

Lots of projects also switched from CVS to bzr.

 I don't see bzr as a big step compared to Git (and in few cases, it's
 worse).

We're not arguing moving *to* bzr from git. Had I spent months setting
up a whole bunch of infrastructure built around git, I'd be rather
attached to that, too.

 You seem to be ignoring the cost of switching. A cost that you're not
 going to pay. I, and the other people working on toooling, are going
 to have to pay it, so yes, I'm feeling rather attached to a lot of our
 existing choices of tools/technology.
 I believe that, in the long run, the cost of learning bzr for each new
 comer, is greater than switching the project to Git.

Depends *very* much on the people. If you just sit down and learn the
3-5 commands needed to get working, the cost is very, very small.  If
you've decided you think it's a bad idea and something you don't want to
learn and you insist on not changing your habits, then the cost is much,
much higher.

Openstack has moved at an incredible pace. Apart from vocal minority who
take every chance to complain about bzr, I don't believe bzr/Launchpad
has been an impediment to attracting developers. Quite the contrary.

 Mistakes with the workflow, like I did when asking you for a review of
 my patches, are even greater costs.

I've been reviewing things for Nova for quite a while now. I do not
recall this having been a problem before.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Martin Pool]

On 22 April 2011 18:07, Robert Collins robert.coll...@canonical.com wrote:
 On Fri, Apr 22, 2011 at 4:11 PM, Thomas Goirand tho...@goirand.fr wrote:

 git checkout -b new-soren-branch

 This is pretty instant. Now do:

 bzr branch trunk new-soren-branch

 and wait for all files to copy ...

 So, bzr had a design concept at the start that folk should start in
 one dir and grow - like RCS - because it gives a /very/ smooth
 learning curve.

If you like reusing one working tree across multiple branches, as is
common in git, I would really recommend you use the bzr-colo plugin,
which automates much of what Robert describes.  Making a new branch in
the same tree is then `bzr colo-branch my-new-branch` and it is pretty
much instant.

http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html

Martin

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Thomas Goirand]

On 04/24/2011 08:27 PM, Soren Hansen wrote:
 There are still *big* projects that still use subversion or even CVS
 (e.g. OpenBSD) and manage to stay productive.

Yes right. So let's go back to use RCS, I'm sure you'll find some
projects still using it! :)

On 04/24/2011 08:27 PM, Soren Hansen wrote:
 Well, that's just silly. On a *really* busy day, I might create 5,
 6 or perhaps even 10 branches, but I make perhaps 50-70 commits.
 Why would the cost of creating branches be so much more interesting
 that you think the time to do anything else *at all* doesn't matter?

Because a commit will always take a very small amount of time, even if
the project is big (eg: about 15 seconds, even on the linux kernel, and
for both git and bzr...). That's currently not truth with a bzr branch
(on a big project), which will always push you to go away take a cup of
coffee 5, 6 or perhaps even 10 times, reducing your productivity, and
making you incredibly addicted to coffee. :)

By the way, I can't even think of making 10 branches a day! My head
would explode, and I wouldn't know what they would be for... :) And
that's precisely what I am not used and dislike with bzr.

Thomas

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Thomas Goirand]

Hi Soren,

On 04/22/2011 08:17 PM, Soren Hansen wrote:
 I wasn't discussing rebasing and hiding trials and errors or even
 rebasing, but cherry-picking things in a branch that we see fits, and
 are ready for a merge.
 
 It may not be completely obvious on the surface, but those are
 essentially the same operation. Rebasing is besically cherry-picking a
 whole bunch of patches and applying them somewhere else.

In Git, when we do git cherry-pick -x sha-sum it takes a patch from
a branch, and put it in another one. That is what I meant. I don't see
how this can be called rebasing. Rebasing is taking patches, and putting
them on top of a branch, right? In my case, before you told me I should
not, I totally rewrote all patches, based on a diff -u -r, to make them
easy to pickup from.

 You rejected a bunch of patches globally because only a tiny portion
 of it aren't ok (like man pages stubs which I though we could work on
 later), which I believe isn't very convenient.
 
 I thought we'd already been through this?

Well, I agreed to work the way you want, because I think that's the
least I can do if you make the effort of reviewing my changes. That
doesn't mean I think it's convenient or the best way to go! :)

Can we agree to not agree? :)

 If I do the way you suggest, either I have to hold so many branches on
 my local disk, which will soon give me headakes and are mistake prone,
 or I have to stop working further on other patches until the previous
 ones are accepted.
 
 Personally, I'm convinvced that having completely separate working
 directories for each feature I'm working on *reduces* my chances of
 mistakes. YMMV.

That's not what I'm saying. I'm saying that, because of your workflow, I
need to use so many branches. If you were cherry-picking things that you
agreed, taking them *on a single branch*, that would be less error prone
for me than having to deal with so many branches. This has nothing to do
with the storage method (eg: physical separate directories in bzr,
which really, I don't mind (apart when projects are growing and bzr
branch starts to become an issue)).

 IMHO, not really relevant. bzr intensively uses branches. Instead, try
 to do:

 git checkout -b new-soren-branch

 This is pretty instant. Now do:

 bzr branch trunk new-soren-branch

 and wait for all files to copy ...
 
 You seem to have missed my final paragraph:
 
 I completely agree that bzr should have better mechanics for sharing
 working trees between different branches (the loom plugin does some of
 this, if you're interested). Apart for when I'm working on the Linux
 kernel, I've never really felt the need for it, but I understand that
 many people do.

I didn't miss it. My point is that bzr is extensively using branching,
so I think that doing a benchmark of any other thing isn't relevant. I
don't really care if a commit takes 15.8 or 16.3 seconds... Even
comparing the branching of Git and the one of bzr isn't helping, because
with Git, you'd do one branch once and for all, and work on it, then ask
someone to merge it or cherry-pick few patches. While with the workflow
we are using with bzr, we'd be doing branching for each single patch we
need to give for review. So, we are actually using quite a lot an
expensive operation.

Also, the linux kernel shouldn't be the only example, there are other
projects that are big (firefox, openoffice, etc) and these wouldn't be
manageable with bzr branching system. Maybe one day, Openstack will grow
too.

 Of course I can't. I'm objecting to the fact that certain conventions
 among users of certain tools encourage moving patches (not code, but
 patches to code. Very different things.)

Call me stupid, but ... can you please explain what's in the brackets? I
really don't get it when you are saying git is a patch management
system and not a VCS, or when you say not code, but patches to code.
Why is bzr different? In what way, new code stored in a patch isn't new
code?

 The problem is that the tools leave *no*
 way to tell if the change has been cherry-picked and taken out of its
 natural context or if it's in the exact place where I wrote it and
 tested it. It's the revision control systems' responsibility to make
 this obvious, and once you accept the concept of rebasing, you're
 instructing your revision control system to lie.

No. You might know it, I don't know. But with git cherry-pick -x, it
does leave clues in the log:

zigo@GPLHost:buzig_ ~/sources/bla$ git log
commit 2ebd1a7555463fe10d5de5cbe2e04469bef9fc47
Author: Jan-XXX x...@xxx.net
Date:   Fri Apr 15 13:43:17 2011 +0200

Support for intermediate certificates for shared ssl.
(cherry picked from commit 5a7ec060fe769b41cf81ca08dcbf6db9e9bc2afa)

Topically, you'd do that a lot with Git, so that patches can go from one
branch to another. It is extremely useful when you are backporting
fixes, for example from a development to a stable branch, and that's one
of the reason why we try to keep history clean in Git.

This is 

Re: [Openstack] Moving code hosting to GitHub

[Robert Collins]

On Fri, Apr 22, 2011 at 4:11 PM, Thomas Goirand tho...@goirand.fr wrote:

 git checkout -b new-soren-branch

 This is pretty instant. Now do:

 bzr branch trunk new-soren-branch

 and wait for all files to copy ...

So, bzr had a design concept at the start that folk should start in
one dir and grow - like RCS - because it gives a /very/ smooth
learning curve.

Unfortunately, it also sucks terribly as your project size grows and
grows and grows. It is however only a /default/ and as such can be
changed.

The bzr project is working (right now) on a fresh /default/ which will
work a lot better. Its also going to be a simpler layout on disk than
the current configuration which works well with really cheap branches.
I've copeid Martin Pool, the project lead, who can talk about the
plans there if you're interested.

Anyhow - this is the cheat sheet for making branches cheap with
vanilla bzr (no plugins needed etc etc):

$ bzr init-repo --no-trees project
$ cd project
$ bzr branch source trunk
$ bzr checkout --lightweight trunk working
# now trunk is a naked branch and working is a historyless checkout

# Key operations:
# make a new branch *and* switch to hacking on it
$ cd working
$ bzr switch -b newbranchname
$ ls ..
$ trunk working newbranchname
$ bzr info | grep checkout of branch:
.../newbranchname

# delete a branch
$ bzr switch trunk
$ rm -r ../newbranchname

# push the current branch
$ bzr push

# push an arbitrary branch (the .. is an artifact of the awkardness
about this setup I
#  mentioned before; it *is* being fixed by the work currently underway.)
$ bzr push -d ../branchname

# Finally, I like having the following config in my
~/.bazaar/locations.conf which lets me do
$ bzr push
# and have bzr Just Know where to push to by default for new branches
# This config is for my launchpad branches
[/home/robertc/launchpad]
submit_branch = /home/robertc/launchpad/devel
public_branch = bzr+ssh://bazaar.launchpad.net/~lifeless/launchpad
public_branch:policy = appendpath
push_location = lp:~lifeless/launchpad
push_location:policy = appendpath
merge_target = /home/robertc/launchpad/devel

I hope this helps with the mind numbing slowness of completely copying
history every time.

PS John Meinel has just made complete history copies take about 70%
less time in bzr trunk.

PPS on the networking side the ticket about network performance in
Shanghai I filed is moving, I've forwarded the trace and will be
following up after easter.

-Rob

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Soren Hansen]

2011/4/22 Thomas Goirand tho...@goirand.fr:
 On 04/22/2011 05:41 AM, Soren Hansen wrote:
 2011/4/21 Thomas Goirand tho...@goirand.fr:
 On 04/19/2011 05:55 AM, Soren Hansen wrote:
 2011/4/18 Thomas Goirand tho...@goirand.fr:
 Can't you just pull each individual patches that you feel ok with?  Is
 it simply not technically possible with bzr?
 Short answer: no. Longer answer: Of course it's possible to extract
 individual patches and apply them elsewhere, but it's tedious, manual
 and throws away history. We bzr users care deeply about history :)
 I don't know bzr enough to be able to tell, but it seems like an area
 of improvement. History, for me, is quite important.
 With Git, it's really easy to get a bunch of patches, select the one we
 want, and reject others. To compete with Git, Bzr *must* be able to do
 that, and allowing rebase and merge of patches in order to keep a clean,
 readable, patch history.
 Rebasing means ripping things out of their context and putting them
[...]
 patches.
 I wasn't discussing rebasing and hiding trials and errors or even
 rebasing, but cherry-picking things in a branch that we see fits, and
 are ready for a merge.

It may not be completely obvious on the surface, but those are
essentially the same operation. Rebasing is besically cherry-picking a
whole bunch of patches and applying them somewhere else. Or, if you
prefer to see it that way, cherry-picking is essentially the process of
rebasing a single commit.

 You rejected a bunch of patches globally because only a tiny portion
 of it aren't ok (like man pages stubs which I though we could work on
 later), which I believe isn't very convenient.

I thought we'd already been through this?

 If I do the way you suggest, either I have to hold so many branches on
 my local disk, which will soon give me headakes and are mistake prone,
 or I have to stop working further on other patches until the previous
 ones are accepted.

Personally, I'm convinvced that having completely separate working
directories for each feature I'm working on *reduces* my chances of
mistakes. YMMV.

 On 04/22/2011 06:36 AM, Soren Hansen wrote:
 All of these were done with a cold cache:

 It took 13.5 seconds to run git diff.
[...]
 Committing a one-line change with bzr commit -m foo filename took
 1.5 seconds.


 IMHO, not really relevant. bzr intensively uses branches. Instead, try
 to do:

 git checkout -b new-soren-branch

 This is pretty instant. Now do:

 bzr branch trunk new-soren-branch

 and wait for all files to copy ...

You seem to have missed my final paragraph:

 I completely agree that bzr should have better mechanics for sharing
 working trees between different branches (the loom plugin does some of
 this, if you're interested). Apart for when I'm working on the Linux
 kernel, I've never really felt the need for it, but I understand that
 many people do.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Thomas Goirand]

On 04/11/2011 09:43 AM, Elliot Murphy wrote:
 Hi!
 
 On Sunday, April 10, 2011, Thomas Goirand tho...@goirand.fr wrote:
 On 04/09/2011 05:21 AM, Jay Pipes wrote:
 All,

 In an effort to speed up our code development processes, reduce the
 friction amongst existing contributors and reduce barriers to entry
 for new contributors familiar with the popular git DVCS, we (the
 OpenStack@Rackspace team) have been studying a transition of our code
 hosting from Launchpad to GitHub. We understand others would be
 proposing the same at the design summit, but we figured it would be
 good to get the discussion started earlier.

 It seems that my previous mail never reached the list, so I'll do again.

 Launchpad is *EXTREMELY* slow from here in Shanghai, and it should be
 even worth from the center of China. Even doing a simple thing like bzr
 launchpad-login can even fail because of connectivity, and I hardly can
 get few KB/s when I do a clone of a bzr repo.

 I mostly don't mind so much bzr, even though starting has been really
 annoying, and that I don't know much about advanced usage like I would
 with Git. But what I welcome the most is the hosting on a platform that
 has an acceptable speed from Asia, which really, isn't the case at all
 for Launchpad. Also, the fact that Git doesn't do network connections
 unless its really needed is very welcome.
 
 I am responsible for supporting the teams that develop and operate
 Launchpad and other tools and systems at Canonical that we provide as
 a high tech incubator of sorts for open source projects.

Having a discussion with Soren about merging a branch, we had the
following discussion:

On 04/19/2011 05:55 AM, Soren Hansen wrote:
 2011/4/18 Thomas Goirand tho...@goirand.fr:
 Can't you just pull each individual patches that you feel ok with?  Is
 it simply not technically possible with bzr?

 Short answer: no. Longer answer: Of course it's possible to extract
 individual patches and apply them elsewhere, but it's tedious, manual
 and throws away history. We bzr users care deeply about history :)

I don't know bzr enough to be able to tell, but it seems like an area of
improvement. History, for me, is quite important.

With Git, it's really easy to get a bunch of patches, select the one we
want, and reject others. To compete with Git, Bzr *must* be able to do
that, and allowing rebase and merge of patches in order to keep a clean,
readable, patch history.

Forcing people into using so many small branches, just in order to
maintain patches separately, doesn't seem convenient. And will take a
lot of useless disk space which, for a big project, can be an issue.
Having to make a copy of 100s of megs just for isolating a small patch
seems quite unreasonable to me (imagine if it was maintained like that
for the Linux kernel, openoffice or firefox, for example...).

I just hope the above help.

Thomas

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Vishvananda Ishaya]

On Apr 21, 2011, at 2:41 PM, Soren Hansen wrote:

 I completely agree that bzr should have better mechanics for sharing
 working trees between different branches (the loom plugin does some of
 this, if you're interested). Apart for when I'm working on the Linux
 kernel, I've never really felt the need for it, but I understand that
 many people do.


This right here is my main issue with bzr.  I can handle the slowness, but I 
find it very difficult to maintain multiple branches and share patches between 
them in bzr.  I end up doing a lot of diff | patch -p0.  I think git's rebase 
is far superior to that workflow.  I'll take a look at loom, sounds interesting.

Vish
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[FUJITA Tomonori]

On Thu, 21 Apr 2011 23:41:35 +0200
Soren Hansen so...@linux2go.dk wrote:

 I find the rebasing/cherry-picking practice even worse in the Linux
 kernel context due to the patch tagging used there. If I add a
 Signed-off-by: Soren Hansen to a patch and someone cherry picks that
 patch or moves it around as part of a rebase, my patch still shows up as
 Signed-off-by: me even though I've never signed off on the patch in
 its new context. I remember at one point I had a patch that added some

Signed-off-by: is not about the context. For Linux kernel, it simply
says that you release your code under GPL. You can't control how other
people use it. That's the fundamental rule under the majority of OSS
licenses. With any tools, you can't the rule. Your code could cause
problems in a different context (you didn't expect), but it's not the
responsibility of your code.

I vote for git. It's much eaiser to try to get your changes merged
into a project that uses git.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Thomas Goirand]

On 04/22/2011 05:41 AM, Soren Hansen wrote:
 2011/4/21 Thomas Goirand tho...@goirand.fr:
 On 04/19/2011 05:55 AM, Soren Hansen wrote:
 2011/4/18 Thomas Goirand tho...@goirand.fr:
 Can't you just pull each individual patches that you feel ok with?  Is
 it simply not technically possible with bzr?
 Short answer: no. Longer answer: Of course it's possible to extract
 individual patches and apply them elsewhere, but it's tedious, manual
 and throws away history. We bzr users care deeply about history :)
 I don't know bzr enough to be able to tell, but it seems like an area
 of improvement. History, for me, is quite important.

 With Git, it's really easy to get a bunch of patches, select the one we
 want, and reject others. To compete with Git, Bzr *must* be able to do
 that, and allowing rebase and merge of patches in order to keep a clean,
 readable, patch history.
 
 Rebasing means ripping things out of their context and putting them
 somewhere else. It not only modifies, but it discards history. As much
 as you may want to alter history, a patch was written when it was
 written and in the context in which it was written. You can rebase all
 you want and make the patches appear in whatever order you please, but
 the true history remains the same: The patch was written in a different
 context at a different time. You are *discarding* the patch history when
 you rebase. There's no longer any way to see the revisions the patch
 went through. You're reducing your revision control system to a patch
 management system. Patch management systems don't care about history of
 your work. They care exclusively about the result: The patch that ends
 up being accepted.
 
 There are several reasons why I strongly oppose this practice:
 
 There's a lot of wisdom to be found in work that gets rejected, and for
 e.g. the Linux kernel, the only way you can see all the patch revisions
 that didn't get approved is by wading through mailing lists. I firmly
 believe this history belongs in the revision control system.  Example:
 Say I'm working on a change to the locking mechanism in a particular
 driver. I look at a similar driver to see how its done there and find
 that it looks needlessly complicated or defensive and I go and implement
 something simpler. Once submitted, it gets torn apart during review
 because there are things I didn't take into account. Had I had easy
 access to the rejected revisions of the same changes to the other
 driver, I could have seen that they tried the same approach and that it
 was changed for this or the other reason and avoided making the same
 mistakes.
 
 There's no shame in writing a patch that doesn't get accepted in the
 first go.  Everyone does it.  Hiding this from the revision history just
 makes it more scary for new people to join in the fun because everyone
 else's work looks to always be perfect even though reality is much, much
 different.
 
 I find the rebasing/cherry-picking practice even worse in the Linux
 kernel context due to the patch tagging used there. If I add a
 Signed-off-by: Soren Hansen to a patch and someone cherry picks that
 patch or moves it around as part of a rebase, my patch still shows up as
 Signed-off-by: me even though I've never signed off on the patch in
 its new context. I remember at one point I had a patch that added some
 security checks to the end of a function. It got rebased and it applied
 cleanly. It took a while before someone noticed that my patches didn't
 work anymore. It turned out that my changes were applied to the
 preceding function, because the two functions shared a bunch of
 boilerplate code at the end (the last 7 lines were actually completely
 identical), so the patch applied cleanly and bunch of other changes made
 it so that the line numbers in my patch now pointed to this other
 function. The problem here is that people were upset, and when they went
 and bisected they could see that I had made this change and signed off
 on it, and wondered what the heck I'd been thinking, and I can honestly
 say I don't blame them.  According to the revision control system, I
 signed off on this change in this context.  Except in the real world, I
 didn't.
 
 Note that I don't mention git or bzr here at all. All of this could
 equally easily happen with bzr or git. Someone did write a rebase plugin
 for bzr, and I hate that with the fire of a thousand suns, too. Just
 because you're holding a gun aimed squarely at your foot, you don't
 *have* to pull the trigger.
 
 Concretely speaking, if you just look at bzr log's default output,
 you'll see a perfectly clean flow of the patches that ended up getting
 accepted. These merge revisions have their own, unique commit message
 that sums up and explains the change.  If you run bzr log -n0, you'll
 see all the gory details of the work leading up to these patches.
 
 I completely agree that bzr should have better mechanics for sharing
 working trees between different branches (the loom plugin does 

Re: [Openstack] Moving code hosting to GitHub

[Robert Collins]

On Tue, Apr 12, 2011 at 7:28 AM, Robert Collins
robert.coll...@canonical.com wrote:
 Don't search: sprint is the one!!! As I'm writing this mail, it's 11pm,
 and I get 20% packet loss... And that's not even peak hours in here
 (which is between 5 and 8pm local time). I can send traceroutes with mtr
 if you like, but I believe it will be annoying reads for the readers of
 this list. Maybe we should switch to private emails?

 The data about sprint is interesting; I'm going to go find the ticket
 we have about performance in china and add this information to it.

I've got a ticket open internally about this; we would appreciate
traceroutes and so forth - lets take that offlist - if you reply just
to me I'll forward it to the sysadmins looking into the issue (and
keep in the loop myself).

I guess initially we need:
 - tcptraceroute on port 22 to bazaar.launchpad.net (has address 91.189.90.11)
 - tcptraceroute on port 443 to launchpad.net (on addresses
91.189.89.222, 91.189.89.223)
 - mtr bazaar.launchpad.net --report-cycles=15
 - mtr launchpad.net --report-cycles=15

And anything else that you think might be interesting to start with.

We have a VPN we can try as well, which can be useful to rule out
various routing policies in the intervening route.

Thanks in advance,
Rob

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Thomas Goirand]

On 04/11/2011 10:52 AM, Robert Collins wrote:
 Also, the fact that Git doesn't do network connections
 unless its really needed is very welcome.

 bzr shouldn't do network connections except when really needed
 *either* : the world is big and networks are slow, so like other DVCS
 the strong preference it has is to cache data locally and only talk on
 the network when really needed.

It unfortunately does. bzr launchpad-login for example does, and if
I'm not mistaking or dreaming, bzr commit as well. Using Git, it's not
the case. The issue isn't to cache data, the issue is that a commit
should *never* access any remote data, so that I could work in the train
without connectivity, for example, and still be able to do bzr commit.
Only pull and push should do network accesses.

 We're desperately short of technical data on the slownesses reported
 from China *specifically*.

I'd be happy to help, but I'm very surprised that you didn't get reports
from Canonical people working in Beijing or Shanghai.

 Things that we'd love to know - how long does SSL handshake take for
 you, do you suffer packet loss talking to our servers, whats the peak
 bandwidth you can get back to our servers.

I can talk for connections from ChinaNet, which is what we have in half
of China, I cannot talk for connectivity using China Unicom (these are
the 2 operators in China, each selling ADSL access to half of the country).

From here, in Shanghai, I hardly get 8KB/s when I do an initial bzr
branch (the equivalent of a clone in Git). That's max speed I saw,
sometimes it is just stuck, and CURL fails to download, getting half a
SSL packet, and printing a Python stack trace.

The reason is simple: the traceroute goes by Sprint, which I believe has
poor connectivity to China (very few times, I see them in the
traceroutes). If you were getting some connectivity by twtelecom (or
maybe by PCCW (the biggest cable operator in Hongkong, but twtelecom is
better), the situation would be much better. We have connectivity from
twtelecom in Atlanta, and it's really good, much better than what we
have in Seattle by HE.

  - we have some analysis about performance of push and pull itself
 which the bzr guys are working on, that will go live as soon as they
 cut another release and we upgrade to bzr $thatversion

I was quite satisfied with the performances of pull and push, the
initial bzr branch lp:xxx was working at 2MB/s on some of my servers.
That's really good, but *if* you have a connection good enough, which
isn't my case when I want to work on my laptop here.

  - we're considering an SSL frontend CDN with a node in asia

Not needed. Just get bandwidth from the correct providers (like
twtelecom or PCCW), and it will be acceptable. Adding a cache wont help
much if the cache is badly connected...

, but its
 not at the very top of the list for performance: we're fixing the
 things that have the most impact - that affect everyone - before we
 start segmenting and improving performance for just one subset of the
 user base.

I'm not talking about *improving* performances, but about simply being
able to barely work with bzr. Can you imagine the frustration when I had
to do 7 times bzr launchpad-login until it worked (and of course,
having to wait for the timeout each time)? Currently, doing that on my
laptop with a direct connection to launchpad is nearly impossible, at
peak hours (like 5 or 6 pm local time). For that reason, I've been
working at night (and also to go on IRC and get in touch with people
helping me to understand Openstack as I discover it). So I have to go
around by my servers, which not everyone can do here (not everyone has
dozens of servers all around the world like I do).

  - the time it takes to deliver the html/json for a page is a key
 metric that we're driving down. 1/2 of the Launchpad developers are
 now in maintenance mode doing performance fixes and customer support.
 I'm completely confident we'll continue to make massive strides on
 this metric in the next 3-6 months. So far, we've dropped the peak
 time - the time the slowest pages in Launchpad take to render - by 9
 seconds (from a peak of 20 seconds).

Frankly, I very rarely do direct connections to websites from here,
because of slowness in China (and simply because I have solutions to
speed-up everything). But that's not the case when I use bzr unless I
use a VPN or something like that, which isn't something I like doing. So
I'm not really the one to ask for the launchpad website performance
feeling.

 - I've been trying to find a Launchpad user there who can help rule
 out whats making things slow.

Don't search: sprint is the one!!! As I'm writing this mail, it's 11pm,
and I get 20% packet loss... And that's not even peak hours in here
(which is between 5 and 8pm local time). I can send traceroutes with mtr
if you like, but I believe it will be annoying reads for the readers of
this list. Maybe we should switch to private emails?

I hope the above helps,

Re: [Openstack] Moving code hosting to GitHub

[Jay Pipes]

Looks like some awesome enhancements. Thanks for the link, Eric!

-jay

On Sat, Apr 9, 2011 at 11:26 PM, Eric Day e...@oddments.org wrote:
 Well, GitHub issues may be a bit more suitable for our needs now:

 https://github.com/blog/831-issues-2-0-the-next-generation

 -Eric

 On Fri, Apr 08, 2011 at 05:21:20PM -0400, Jay Pipes wrote:
 All,

 In an effort to speed up our code development processes, reduce the
 friction amongst existing contributors and reduce barriers to entry
 for new contributors familiar with the popular git DVCS, we (the
 OpenStack@Rackspace team) have been studying a transition of our code
 hosting from Launchpad to GitHub. We understand others would be
 proposing the same at the design summit, but we figured it would be
 good to get the discussion started earlier.

 GitHub has a number of major strengths when it comes to managing source code:
 - Contributors seem to be more familiar with, and comfortable using, git
 - The code review process on GitHub is easier to use for reviewers
   who use the website interface and allows for fine-grained comment
   control per line in diffs

 As good as the GitHub review system is, there are some deficiencies,
 such as the lack of ability to mark a request as definitively
 approved. We hope to work with the GitHub team to investigate how this
 can be rectified.

 Of course, there is much more to delivering a professionally released
 open source software package than just the code hosting platform. This
 is the primary interface for code contributors who are actively
 developing, but the project also needs to have processes in place for
 handling bug reports, managing distribution, packaging, translations,
 and releasing the code in an efficient manner.

 There are a number of things that Launchpad provides OpenStack
 projects that GitHub does not have the ability to do. Examples of
 these things include translation services, project management
 abilities, package archives for projects, and release-management
 functionality.

 Therefore, at this time, we are only proposing moving the code hosting
 functionality to GitHub, and not radically changing any other parts of
 the development and release process.

 Soren, Monty, and Thierry, who are the developers responsible for
 keeping our release management and development infrastructure in good
 shape, have identified the pieces of our existing infrastructure that
 they will have to modify. Some of these changes are small, some
 require a bit more work. They are all committed to making these
 changes and to moving us along in the process of transitioning code
 hosting over to GitHub.

 There will be a design summit session about this transition where the
 process will be discussed in more detail, as well as the possibility
 to migrate other parts of our infrastructure.

 Comments and discussion welcome.

 Cheers,
 -jay

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to     : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Robert Collins]

On Tue, Apr 12, 2011 at 3:13 AM, Thomas Goirand tho...@goirand.fr wrote:
 I'm not mistaking or dreaming, bzr commit as well. Using Git, it's not
 the case. The issue isn't to cache data, the issue is that a commit
 should *never* access any remote data, so that I could work in the train
 without connectivity, for example, and still be able to do bzr commit.
 Only pull and push should do network accesses.

If 'bzr commit' is doing network access, its been configured to work
directly with a branch over the network, or you have a plugin that is
doing network access. The former may have been done for workflow
reasons in maintaining the trunk - but that surprises me as I thought
your project was using tarmac, where you would only push to personal
branches and the robot would test and promote branches that pass the
test suite.

The next time you observe 'bzr commit' do networking, could you grab a
'bzr info' from that tree and show it to me, or #bzr on freenode, and
we can sort out what is up.

 We're desperately short of technical data on the slownesses reported
 from China *specifically*.

 I'd be happy to help, but I'm very surprised that you didn't get reports
 from Canonical people working in Beijing or Shanghai.

Sadly no, the folk I hear about suffering are staff on-site with other
companies, and I haven't managed to get the contacts in place to
diagnose yet.


  - we're considering an SSL frontend CDN with a node in asia

 Not needed. Just get bandwidth from the correct providers (like
 twtelecom or PCCW), and it will be acceptable. Adding a cache wont help
 much if the cache is badly connected...

It wouldn't cache, just do SSL in the region; this could help in a few ways:
 - we could get bandwidth to it from twtelecom
 - it would be close enough to do ssl handshaking in ~ 1 second rather
than the many seconds you're paying at the moment
 - we would have dedicated backhaul bandwidth on it to our primary
datacentre (London) rather than depending on local ISP prioritisation.

Anyhow -
...
 Don't search: sprint is the one!!! As I'm writing this mail, it's 11pm,
 and I get 20% packet loss... And that's not even peak hours in here
 (which is between 5 and 8pm local time). I can send traceroutes with mtr
 if you like, but I believe it will be annoying reads for the readers of
 this list. Maybe we should switch to private emails?

The data about sprint is interesting; I'm going to go find the ticket
we have about performance in china and add this information to it.

Thanks!
Rob

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Elliot Murphy]

Hi!

On Sunday, April 10, 2011, Thomas Goirand tho...@goirand.fr wrote:
 On 04/09/2011 05:21 AM, Jay Pipes wrote:
 All,

 In an effort to speed up our code development processes, reduce the
 friction amongst existing contributors and reduce barriers to entry
 for new contributors familiar with the popular git DVCS, we (the
 OpenStack@Rackspace team) have been studying a transition of our code
 hosting from Launchpad to GitHub. We understand others would be
 proposing the same at the design summit, but we figured it would be
 good to get the discussion started earlier.

 It seems that my previous mail never reached the list, so I'll do again.

 Launchpad is *EXTREMELY* slow from here in Shanghai, and it should be
 even worth from the center of China. Even doing a simple thing like bzr
 launchpad-login can even fail because of connectivity, and I hardly can
 get few KB/s when I do a clone of a bzr repo.

 I mostly don't mind so much bzr, even though starting has been really
 annoying, and that I don't know much about advanced usage like I would
 with Git. But what I welcome the most is the hosting on a platform that
 has an acceptable speed from Asia, which really, isn't the case at all
 for Launchpad. Also, the fact that Git doesn't do network connections
 unless its really needed is very welcome.

I am responsible for supporting the teams that develop and operate
Launchpad and other tools and systems at Canonical that we provide as
a high tech incubator of sorts for open source projects.

We have heard complaints about slowness from china before, and about
slowness of Launchpad even outside of china. Over the last few months
we have made huge improvements to performance outside of china, and
have begun thinking about options for speeding things up inside china.
It would be fantastic to get some help from you with specific
technical detail about what is most painfully slow (perhaps off list),
and it would also be fantastic to get pointers to sites that you find
have outstanding performance in china. I have CC'd Rob who is the
Launchpad technical architect, he has been the driver of our recent
performance push.

To the open stack community on general, i'd like to say: GitHub
absolutely rocks, nothing but love for them. But please know that we
are delighted and proud to have open stack using Launchpad and bazaar,
and I don't want you to leave without having a chance to make things
perfect for you. In fact we are sending a Launchpad and bazaar
developer to the upcoming openstack summit.

-- 
Elliot Murphy | https://launchpad.net/~statik/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Eric Day]

Well, GitHub issues may be a bit more suitable for our needs now:

https://github.com/blog/831-issues-2-0-the-next-generation

-Eric

On Fri, Apr 08, 2011 at 05:21:20PM -0400, Jay Pipes wrote:
 All,
 
 In an effort to speed up our code development processes, reduce the
 friction amongst existing contributors and reduce barriers to entry
 for new contributors familiar with the popular git DVCS, we (the
 OpenStack@Rackspace team) have been studying a transition of our code
 hosting from Launchpad to GitHub. We understand others would be
 proposing the same at the design summit, but we figured it would be
 good to get the discussion started earlier.
 
 GitHub has a number of major strengths when it comes to managing source code:
 - Contributors seem to be more familiar with, and comfortable using, git
 - The code review process on GitHub is easier to use for reviewers
   who use the website interface and allows for fine-grained comment
   control per line in diffs
 
 As good as the GitHub review system is, there are some deficiencies,
 such as the lack of ability to mark a request as definitively
 approved. We hope to work with the GitHub team to investigate how this
 can be rectified.
 
 Of course, there is much more to delivering a professionally released
 open source software package than just the code hosting platform. This
 is the primary interface for code contributors who are actively
 developing, but the project also needs to have processes in place for
 handling bug reports, managing distribution, packaging, translations,
 and releasing the code in an efficient manner.
 
 There are a number of things that Launchpad provides OpenStack
 projects that GitHub does not have the ability to do. Examples of
 these things include translation services, project management
 abilities, package archives for projects, and release-management
 functionality.
 
 Therefore, at this time, we are only proposing moving the code hosting
 functionality to GitHub, and not radically changing any other parts of
 the development and release process.
 
 Soren, Monty, and Thierry, who are the developers responsible for
 keeping our release management and development infrastructure in good
 shape, have identified the pieces of our existing infrastructure that
 they will have to modify. Some of these changes are small, some
 require a bit more work. They are all committed to making these
 changes and to moving us along in the process of transitioning code
 hosting over to GitHub.
 
 There will be a design summit session about this transition where the
 process will be discussed in more detail, as well as the possibility
 to migrate other parts of our infrastructure.
 
 Comments and discussion welcome.
 
 Cheers,
 -jay
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Andrew Shafer]

Hurray!
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Paul Voccio]

Jay,

I think that discussion will be one of the more popular talks at the
summit. Looking forward to the discussion. I know a lot of devs will be
happy to see this. 

pvo

On 4/8/11 4:21 PM, Jay Pipes jaypi...@gmail.com wrote:

All,

In an effort to speed up our code development processes, reduce the
friction amongst existing contributors and reduce barriers to entry
for new contributors familiar with the popular git DVCS, we (the
OpenStack@Rackspace team) have been studying a transition of our code
hosting from Launchpad to GitHub. We understand others would be
proposing the same at the design summit, but we figured it would be
good to get the discussion started earlier.

GitHub has a number of major strengths when it comes to managing source
code:
- Contributors seem to be more familiar with, and comfortable using, git
- The code review process on GitHub is easier to use for reviewers
  who use the website interface and allows for fine-grained comment
  control per line in diffs

As good as the GitHub review system is, there are some deficiencies,
such as the lack of ability to mark a request as definitively
approved. We hope to work with the GitHub team to investigate how this
can be rectified.

Of course, there is much more to delivering a professionally released
open source software package than just the code hosting platform. This
is the primary interface for code contributors who are actively
developing, but the project also needs to have processes in place for
handling bug reports, managing distribution, packaging, translations,
and releasing the code in an efficient manner.

There are a number of things that Launchpad provides OpenStack
projects that GitHub does not have the ability to do. Examples of
these things include translation services, project management
abilities, package archives for projects, and release-management
functionality.

Therefore, at this time, we are only proposing moving the code hosting
functionality to GitHub, and not radically changing any other parts of
the development and release process.

Soren, Monty, and Thierry, who are the developers responsible for
keeping our release management and development infrastructure in good
shape, have identified the pieces of our existing infrastructure that
they will have to modify. Some of these changes are small, some
require a bit more work. They are all committed to making these
changes and to moving us along in the process of transitioning code
hosting over to GitHub.

There will be a design summit session about this transition where the
process will be discussed in more detail, as well as the possibility
to migrate other parts of our infrastructure.

Comments and discussion welcome.

Cheers,
-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message. 
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Naveed Massjouni]

On Fri, Apr 8, 2011 at 5:21 PM, Jay Pipes jaypi...@gmail.com wrote:
 All,

 In an effort to speed up our code development processes, reduce the
 friction amongst existing contributors and reduce barriers to entry
 for new contributors familiar with the popular git DVCS, we (the
 OpenStack@Rackspace team) have been studying a transition of our code
 hosting from Launchpad to GitHub. We understand others would be
 proposing the same at the design summit, but we figured it would be
 good to get the discussion started earlier.

 GitHub has a number of major strengths when it comes to managing source code:
 - Contributors seem to be more familiar with, and comfortable using, git
 - The code review process on GitHub is easier to use for reviewers
  who use the website interface and allows for fine-grained comment
  control per line in diffs

 As good as the GitHub review system is, there are some deficiencies,
 such as the lack of ability to mark a request as definitively
 approved. We hope to work with the GitHub team to investigate how this
 can be rectified.

 Of course, there is much more to delivering a professionally released
 open source software package than just the code hosting platform. This
 is the primary interface for code contributors who are actively
 developing, but the project also needs to have processes in place for
 handling bug reports, managing distribution, packaging, translations,
 and releasing the code in an efficient manner.

 There are a number of things that Launchpad provides OpenStack
 projects that GitHub does not have the ability to do. Examples of
 these things include translation services, project management
 abilities, package archives for projects, and release-management
 functionality.

 Therefore, at this time, we are only proposing moving the code hosting
 functionality to GitHub, and not radically changing any other parts of
 the development and release process.

Does this mean we will have to continue using launchpad/bzr for merge
props for the near future? I don't understand what would be the
advantage for developers in that case.
-Naveed


 Soren, Monty, and Thierry, who are the developers responsible for
 keeping our release management and development infrastructure in good
 shape, have identified the pieces of our existing infrastructure that
 they will have to modify. Some of these changes are small, some
 require a bit more work. They are all committed to making these
 changes and to moving us along in the process of transitioning code
 hosting over to GitHub.

 There will be a design summit session about this transition where the
 process will be discussed in more detail, as well as the possibility
 to migrate other parts of our infrastructure.

 Comments and discussion welcome.

 Cheers,
 -jay

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to     : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Rick Clark]

 
 Therefore, at this time, we are only proposing moving the code hosting
 functionality to GitHub, and not radically changing any other parts of
 the development and release process.
 
 Soren, Monty, and Thierry, who are the developers responsible for
 keeping our release management and development infrastructure in good
 shape, have identified the pieces of our existing infrastructure that
 they will have to modify. Some of these changes are small, some
 require a bit more work. They are all committed to making these
 changes and to moving us along in the process of transitioning code
 hosting over to GitHub.


Are you implying that the decision had been made to move to github?

This all sounds extremely disruptive for a project that has successfully
managed phenomenal growth. I think we need to make sure this discussion
includes all parties that have an interest in following the release and
development of Openstack.



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Jesse Andrews]

The decision hasn't been made.  The decision is to talk about it at the summit 
and on the mailing list.

-- Sent from my Tandy 1000sx

Jesse Andrews
anotherje...@gmail.com



On Apr 8, 2011, at 3:08 PM, Rick Clark wrote:

 
 Therefore, at this time, we are only proposing moving the code hosting
 functionality to GitHub, and not radically changing any other parts of
 the development and release process.
 
 Soren, Monty, and Thierry, who are the developers responsible for
 keeping our release management and development infrastructure in good
 shape, have identified the pieces of our existing infrastructure that
 they will have to modify. Some of these changes are small, some
 require a bit more work. They are all committed to making these
 changes and to moving us along in the process of transitioning code
 hosting over to GitHub.
 
 
 Are you implying that the decision had been made to move to github?
 
 This all sounds extremely disruptive for a project that has successfully
 managed phenomenal growth. I think we need to make sure this discussion
 includes all parties that have an interest in following the release and
 development of Openstack.
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Moving code hosting to GitHub

[Monty Taylor]

On 04/08/2011 02:51 PM, Naveed Massjouni wrote:
 On Fri, Apr 8, 2011 at 5:21 PM, Jay Pipes jaypi...@gmail.com wrote:
 All,

 In an effort to speed up our code development processes, reduce the
 friction amongst existing contributors and reduce barriers to entry
 for new contributors familiar with the popular git DVCS, we (the
 OpenStack@Rackspace team) have been studying a transition of our code
 hosting from Launchpad to GitHub. We understand others would be
 proposing the same at the design summit, but we figured it would be
 good to get the discussion started earlier.

 GitHub has a number of major strengths when it comes to managing source code:
 - Contributors seem to be more familiar with, and comfortable using, git
 - The code review process on GitHub is easier to use for reviewers
  who use the website interface and allows for fine-grained comment
  control per line in diffs

 As good as the GitHub review system is, there are some deficiencies,
 such as the lack of ability to mark a request as definitively
 approved. We hope to work with the GitHub team to investigate how this
 can be rectified.

 Of course, there is much more to delivering a professionally released
 open source software package than just the code hosting platform. This
 is the primary interface for code contributors who are actively
 developing, but the project also needs to have processes in place for
 handling bug reports, managing distribution, packaging, translations,
 and releasing the code in an efficient manner.

 There are a number of things that Launchpad provides OpenStack
 projects that GitHub does not have the ability to do. Examples of
 these things include translation services, project management
 abilities, package archives for projects, and release-management
 functionality.

 Therefore, at this time, we are only proposing moving the code hosting
 functionality to GitHub, and not radically changing any other parts of
 the development and release process.
 
 Does this mean we will have to continue using launchpad/bzr for merge
 props for the near future? I don't understand what would be the
 advantage for developers in that case.
 -Naveed

For the near future, yes.

Even if we were to decide to move to git/github _today_ there is a
fairly enormous amount of process and automation built around
bzr/launchpad at the moment that has to be dealt with/migrated.

However - if your question is if we do move to git/github for code
hosting, will we still use bzr/launchpad for merge props at that point
the answer would most certainly be no.

 Soren, Monty, and Thierry, who are the developers responsible for
 keeping our release management and development infrastructure in good
 shape, have identified the pieces of our existing infrastructure that
 they will have to modify. Some of these changes are small, some
 require a bit more work. They are all committed to making these
 changes and to moving us along in the process of transitioning code
 hosting over to GitHub.

 There will be a design summit session about this transition where the
 process will be discussed in more detail, as well as the possibility
 to migrate other parts of our infrastructure.

 Comments and discussion welcome.

 Cheers,
 -jay

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp