First off: this is not an attempt at a "strong objection" to delay or change Jeff's stated plan.
Just my view as somebody who already contributes to projects hosted on both GH and BB: Since the bulk of the DVCS "work" as a developer is (in my experience) done at the git command line, the choice of hosting provider is not something that matters "day to day". For me the per-branch ACLs at BB is (as has been proposed here) used as a simple mechanism to ensure a release branch can only be modified by the RM/GK. However, I suspect that a (public) fork (perhaps owned by the RM?) would be a perfectly usable alternative at GH (sounds like that, or the inverse in which the trunk is the fork, is Jeff's plan). The GUIs for things like browsing commits, viewing diffs, etc are pretty similar in capability and each is sufficiently intuitive (after a brief learning curve) that I don't find I need any conscious effort to "mode switch" between their use. The ability to comment on commits in lieu of the ticket system is a good feature, for instance, that "just works" in both systems. The same goes for pull-requests, though the two sites treat them a bit differently (they are integrated with the issue tracker at GH and a distinct object type at BB). Caveat: I don't do things via GUI when I know of a command line equivalent (for instance, I don't create, destroy or merge branches using the GUI), and therefore I am probably not pushing the limits of either. Site navigation is essentially the same, but with icons on the left vs right. Once you learn the navigation icons, I again find no conscious effort to switch between them. Each has minor quirks, and both sites make changes occasionally (and without advance warning that I am aware of). Personally, I don't like the issue trackers at either site as compared to Trac or Bugzilla. The available feature set in each is small enough that in my experience if you can't immediately figure out how to do something, it is probably because you can't do it at all. In short, I find that switching between BB and GH is far easier than switching among CVS, SVN and Git (which I also have to do because of the variety of projects I work on or follow trunk/head/tip development of). So if, as Jeff suggests might happen, the OMPI community eventually finds work split between BB and GH, then I don't personally think it is going to be a productivity-killer. -Paul Disclaimer: My employer pays for an institutional Unlimited account at BB, which then owns all of our repos (project leads just get Admin status). So, I host my own projects at BB without any objective evaluation of the relative costs or merits of the hosting providers. On Thu, Sep 25, 2014 at 11:42 AM, Jeff Squyres (jsquyres) < jsquy...@cisco.com> wrote: > I had a look at bitbucket. > > SHORT VERSION > > I'm inclined to stick with Github. If no one strongly disagrees, I'll > proceed with the GitHub migration next Wednesday, 1 Oct, 2014, starting at > 8am US Eastern. > > MORE DETAIL > > All in all, there is massive overlap of features between Github and > Bitbucket. There's a few on each that aren't in the other, obviously > (e.g., per-branch push ACLs at Bitbucket), but all in all, they're very > similar. > > The cost model is a major difference. At first look, OMPI had 42 unique > committers over the last 12 months, which means we'd be on the 50-user plan > at $50/mo ($600/yr). This is twice as expensive at Github ($300/yr so we > can have 10 private repos). The cost difference is not an automatic > deal-breaker, but it is something to note. Plus, since we used 42 > committers last year, it's not inconceivable that we'll have to play tricks > sometimes to stay under 50 committers (i.e., pruning accounts more than > once a year). Since I'm the guy that typically has to handle that kind of > stuff, I'm not very excited about that prospect. > > I asked GitHub if they were going to support per-branch push ACLs. They > gave an unsurprising "Thanks for your comments! We'll add it to the list > of suggestions" kind of answer. The exact text of their reply actually > gave me a little hope that they're at least seriously thinking about it, > but it is definitely not a promise of future functionality. > > As I mentioned in the prior email, one possibility is that we could take > the main OMPI repo to BB and leave everything else as GH. > > In reality, ORCM would likely also follow (since it's closely related to > OMPI -- it uses OPAL and ORTE). And Dave/Ralph/I are discussing the > possibility of using git subtrees to split OPAL and ORTE into their own > repos (this is all talk at the moment -- don't worry). If that happens, > they'll likely be at BH with the main OMPI repo. > > As such, we'd end up with a bit of split-brain -- some repos at BB and > some at GH. Keep in mind that this is two different web UIs, two different > ticket systems, two different wiki formats, etc. For those of us who work > in multiple different projects in OMPI, it could be annoying to have to > mentally switch between the two. > > Don't get me wrong: using two different systems is definitely do-able, > but... meh. > > All in all, I think it distills down to: > > 1. There's one feature we hope GitHub will implement (per-branch push > ACLs; we can easily switch from a two-repo system to a single-repo system > if they ever do); Bitbucket has this feature today. Otherwise, BB vs. GH = > pretty feature-comparable. > > 2. Bitbucket is a bit more expensive / Cisco already paid for GitHub. As > a side-effect, using Bitbucket *may* result in committer-counting games (to > stay on a given plan). > > 3. All the rest of OMPI projects are at GitHub > > Because of inertia, monetary cost, an logistics/mental cost, I'm inclined > to stick with the existing migration plan and move the main Open MPI repo > to GitHub next Wednesday, 1 Oct 2014, starting at 8am US Eastern. > > Comments? > > > > > On Sep 24, 2014, at 6:37 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > > > If someone with a .edu account gets us a free Bitbucket for Open MPI, > and then we use it for both research and industry stuff... at best, I think > that falls into a grey area as to whether this is within Bitbucket's TOS > (disclaimer: I haven't read their TOS). It still sounds like a murky > prospect; I'm not sure it's within the intent of a free account. > > > > Paying a reasonable amount for a private account isn't out of the > question. Indeed, Cisco has already paid $300 for the first year of a > Github account so that OMPI can have a private repo. :-\ That can be > written off, if necessary, but it would be nice not to. However, paying > per developer may become prohibitive -- infrequent bulk payments (e.g., > $300/year) are do-able from those of us at corporations. Managing a > monthly fee that is dependent upon the number of active committers (and > that number changes over time) could get a bit... complex, in terms of > corporate payments / reimbursements. > > > > That being said, there's quite a bit of OMPI infrastructure that is > actively in use at GitHub. It would be a bit of a pain to migrate all of > that *again* (from SVN/Trac -> Git/Github -> Git/Bitbucket). Remember, > it's not just moving the repos (which, since most repos are now Git, is > easy to move to another hosting provider); it's also moving the wiki and > the tickets, too. That will take more effort. > > > > All the above being said: > > > > 1. I'll still have a look at Bitbucket today. It may be a workable > model that the main OMPI repo (and wiki and tickets) is at Bitbucket, and > most other repos (and wikis and tickets) are at Github. > > 2. I just sent a mail to Github support asking them if they plan to > support per-branch push ACLs. I don't know if they'll be able to give a > direct answer, but it's worth asking. > > > > It would be a little weird to span Github and Bitbucket, but the > individual OMPI sub-projects are suitably independent of each other such > that it could work. Indeed, we've effectively been doing that for a while > (e.g., hwloc has been at Github for quite a few months now), but that was > never intended to be the desired end state. > > > > > > > > On Sep 23, 2014, at 11:57 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > > >> The pricing question might not be as simple as it first sounds. At > BitBucket Academic accounts are free and allow unlimited users. So, if > somebody with an .EDU email address (IU and UTK come to mind) are the > owners of the repo then I believe the cost is zero. Somebody should verify > that rather than take my word for it. > >> > >> More points for comparison between BitBucket and GitHub are presented in > >> > http://www.infoworld.com/article/2611771/application-development/bitbucket-vs--github--which-project-host-has-the-most-.html > >> > >> -Paul > >> > >> On Tue, Sep 23, 2014 at 8:39 PM, Gilles Gouaillardet < > gilles.gouaillar...@iferc.org> wrote: > >> my 0.02 US$ ... > >> > >> Bitbucket pricing model is per user (but with free public/private > >> repository up to 5 users) > >> whereas github pricing is per *private* repository (and free public > >> repository and with unlimited users) > >> > >> from an OpenMPI point of view, this means : > >> - with github, only the private ompi-tests repository requires a fee > >> - with bitbucket, the ompi repository requires a fee (there are 119 > >> users in https://github.com/open-mpi/authors/blob/master/authors.txt, > in > >> bitbucket pricing model, that means unlimited users and this is 200US$ > >> per month) > >> > >> per branch ACL is a feature that was requested loooong time ago on > >> bitbucket, and now they implemented it, i would not expect it takes > >> too much time before github implements it too. > >> > >> from the documentation, gerrithub has also interesting features : > >> - force the use of a workflow (assuming the workflow is a good match > >> with how we want to work ...) > >> - prevent developers from commiting a huge mess to github > >> > >> Gilles > >> > >> On 2014/09/24 10:36, Jeff Squyres (jsquyres) wrote: > >>> On Sep 23, 2014, at 7:52 PM, Jed Brown <j...@jedbrown.org> wrote: > >>> > >>>> I don't have experience with GerritHub, but Bitbucket supports this > >>>> feature (permissions on branch names/globs) and we use it in PETSc. > >>> Thanks for the info. Paul Hargrove said pretty much the same thing to > me, off-list. > >>> > >>> I'll check it out. > >>> > >> > >> _______________________________________________ > >> devel mailing list > >> de...@open-mpi.org > >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >> Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/09/15909.php > >> > >> > >> > >> -- > >> Paul H. Hargrove phhargr...@lbl.gov > >> Future Technologies Group > >> Computer and Data Sciences Department Tel: +1-510-495-2352 > >> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > >> _______________________________________________ > >> devel mailing list > >> de...@open-mpi.org > >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >> Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/09/15910.php > > > > > > -- > > Jeff Squyres > > jsquy...@cisco.com > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/09/15911.php > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/09/15916.php > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
