19:05:30 <mtaylor> #startmeeting
19:05:31 <openstack> Meeting started Tue Aug  9 19:05:30 2011 UTC.  The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:06:12 <mtaylor> #topic Actions from last meeting
19:06:26 <mtaylor> Real quick update on stuff from last week:
19:06:38 <mtaylor> The milestone proposed jobs were fixed and can run on the right build slaves now
19:07:04 <mtaylor> tarball_script.sh and ppa_script.sh were updated for the glance transition
19:07:22 <mtaylor> and jaypipes and I did nothing on the glance upgrade path testing job
19:07:34 <mtaylor> #action jaypipes design upgrade path jenkins job with mtaylor
19:07:41 <mtaylor> #topic open discussion
19:07:56 <notmyname> mtaylor: how goes gitweb/gitorious?
19:08:05 <mtaylor> on positive notes - glance migrated to git/gerrit
19:08:27 <mtaylor> notmyname: we spun up a gitweb and I've been poking at gitorious
19:08:47 <notmyname> cool. just curious to see the differences
19:08:51 <mtaylor> notmyname: I think that gitorious could be a solution even using gitorious.org - but I think we could do some additional integration if we ran our own
19:08:57 <bengrue> why not github?
19:09:09 <bengrue> (Did I miss something earlier?)
19:09:20 <mtaylor> notmyname: I set up https://gitorious.org/openstack just to look at it
19:09:31 <bengrue> lack of collaboration tools?
19:09:42 <notmyname> bengrue: with gerrit, we wouldn't use any github features
19:09:53 <mtaylor> bengrue: longer ongoing discussion - but it has been put across that if we aren't using pull requests, then putting branches on github is confusing
19:10:01 <mtaylor> which is, I think, correct
19:10:46 <mtaylor> notmyname: the hosted gitorious.org does allow you to turn off merge requests ... so that's workable - however, I was going to spin up an instance locally and see what that looked like
19:10:59 <jeblair> if we do use github, we might try to auto-respond to pull requests (either by converting them to gerrit changes, or closing them with a message pointing to gerrit)
19:11:15 <mtaylor> cause if we're going to do that - perhaps having it at git.openstack.org might be preferrable
19:11:26 <mtaylor> jeblair: is the gitweb thing from gerrit publicly accessible?
19:11:53 <mtaylor> notmyname: also, it's notable that gerrit themselves don't use the bundled gitweb and instead use a gitweb running elsewhere that they mirror to
19:11:59 <bengrue> There are hooks we can fire in github upon pull request, right?
19:12:03 <notmyname> interesting
19:12:26 <jeblair> it's only on a dev server, and it's mostly useful for viewing the state of the gerrit repo.  i think we should turn it on on the production server, because it's free.
19:12:40 <mtaylor> bengrue: yes - there are hooks - but for what purpose are you suggesting?
19:12:55 <jeblair> however, i don't think it's a good public entry point to viewing the repos.  for that, if we wanted to use gitweb, we should probably have a separate server
19:13:25 <jeblair> (or a separate gitweb instance)
19:13:52 <jeblair> like: https://android.git.kernel.org/?p=tools/gerrit.git
19:14:03 <jeblair> is separate from: https://review.source.android.com/#/q/status:open,n,z
19:14:33 <bengrue> mtayor: I was following up on jeblair's statement about auto-responding/converting-to-gerrit for clarification
19:14:45 <mtaylor> bengrue: ah. cool.
19:14:48 <mtaylor> bengrue: and yes
19:15:48 <mtaylor> that would likely be how we would go about such a thing ... however, I think the point made that it might just be eaiser for folks to grok if we weren't showing pull requests at all might make more sense
19:17:21 <notmyname> unfotunately (for this use case), pull requests are so deeply integrated into github that hiding them would be unlikely
19:17:32 <mtaylor> agree
19:18:22 <notmyname> so, if we can't use github's pull requests, issues, etc (/sad notmyname), then I think we should avoid the confusion
19:19:06 <mtaylor> notmyname: any thoughts on hosted gitorious vs. us running one just on general principle?
19:19:07 <bengrue> What's specifically the problem with pull requests?  openstack has too many?
19:19:07 <notmyname> but, I'd like to see the options before committing to one or the other (thanks to mtaylor and jeblair for the effort of looking in to it all)
19:19:27 <mtaylor> bengrue: I just sent a follow up email to the openstack mailing list about that
19:19:35 <notmyname> bengrue: "they" ;-) want gated trunks
19:19:42 <mtaylor> notmyname: :)
19:19:45 <bengrue> Who are "they"?
19:20:09 <mtaylor> bengrue: you will find that we have a multitude of opinions and goals ;)
19:20:18 <bengrue> Indeed.
19:20:39 <bengrue> We are OpenLegion, for we are many.
19:20:45 <mtaylor> hahaha
19:20:47 <mtaylor> hahahahaha
19:20:53 <notmyname> mtaylor: no opinions on hosted or self-hosted. however, we are hosting part of it and do have a large hosting company helping out openstack....
19:20:56 <mtaylor> ok - that may be the funniest thing I've heard in this context in months
19:21:05 <mtaylor> notmyname: that was sort of my thought
19:21:08 <termie> we chatted a bit about this in the office yesterday
19:21:24 <mtaylor> notmyname: once we crossed the line of "hosting some of it" ... hosting more of it isn't really much more of an imposition :)
19:21:28 <termie> we felt there were still useful things for using github as we do a lot of collab that is outside of just pushing code reviews
19:21:55 <mtaylor> totally - and those things can still really be done no matter what
19:22:12 <termie> sure, but github offers a useful multi-user environment
19:22:23 <mtaylor> no - I meant github can still be used for those no matter what
19:23:18 <jeblair> mtaylor: you mean, even if the "official" location is gitorious or gitweb?
19:23:25 <termie> we also brought up that a lot of people currenlty _are_ using github for issues
19:23:57 <mtaylor> yes they are ... although none of those issues are in the set of project tracked and officially planned for issues
19:24:08 <bengrue> We currently (at Piston) have an internal cron that polls launchpad every 20 minutes and shoves it into github.
19:24:35 <bengrue> nova and swift, at least.  not every project.
19:24:45 <notmyname> bengrue: issues?
19:24:50 <notmyname> or code?
19:25:03 <mtaylor> the main issue feature requirement that has been stated is the ability to attach an issue to more than one project and/or more than one release of a project
19:25:03 <bengrue> none yet, we're just starting to use it... I'm sure there will be some.
19:25:06 <bengrue> Oh, code.
19:25:10 <bengrue> Sorry.
19:25:30 <mtaylor> but I'm actually interested in clarifying termie's point from earlier
19:25:35 <notmyname> bengrue: the "unoficial" swift mirror is kept up to date (http://github.com/openstack/swift)
19:25:49 <bengrue> notmyname: ah, nice.
19:26:07 <notmyname> bengrue: i'd suggest keeping that repo as an upstream remote
19:26:09 <termie> my only point is that i don't think there is sufficient reason to self-host the git parts, i think we are actually getting stuff out of github even if not using it for official pull requests or issues
19:26:21 <mtaylor> termie: are you saying you think that just continuing to mirror to github and telling people to use gerrit ...
19:26:31 <mtaylor> termie: you answered even as I was asking
19:26:39 <notmyname> termie: what about confusion of how to get stuff in to master?
19:27:04 <termie> notmyname: either automated thing telling people who send pull requests to master to use gerrit or get gerrit to bring them in
19:27:09 <notmyname> I've only seen 1 issue come up on github for swift, and I hate having to tell that person "sorry, learn bzr/lp and resubmit"
19:27:12 <termie> notmyname: pretty easy cronjob to write
19:27:13 <mtaylor> notmyname: it's really only confusion the first time someone tries to submit ... and a github hook that gave someone to ping them
19:27:34 <termie> you can disable issues for the project
19:27:43 <bengrue> Automated messages explaining what to do when the "wrong" thing is done is a favorite method of mine.
19:27:47 <bengrue> It's passive education.
19:27:52 <notmyname> termie: ya, actually it was a pull request
19:27:53 <mtaylor> and easy to accomplish
19:27:57 <bengrue> It leads to immediate discoverability.
19:28:11 <termie> (though obvs i still think we should ditch launchpad with haste on all possible fronts)
19:28:26 <notmyname> if pull request hooks solve the problem, that may be sufficient
19:29:04 <bengrue> I'm relatively new to openstack development myself, and I'd say there are some hard to discover things all over the project.  The clearer the feedback on bad actions, the easier it becomes to bootstrap into the project.
19:29:05 <mtaylor> I would say a) auto responses to pull requests with links to gerrit instructions and b) look in to whether it makes physical sense to auto-create a gerrit request for them - yeah?
19:29:10 <mtaylor> #info termie hates launchpad
19:29:19 <jeblair> here's a quick comparison of the things we've looked at:
19:29:20 <termie> mtaylor: wouldn't want my position to be clouded
19:29:25 <jeblair> github: unable to disable pull requests, so we would have to either attempt to automatically move them to gerrit or automatically close them with instructions pointing to gerrit.  does not support openid as a provider or consumer, so separate authn needed.
19:29:27 <mtaylor> termie: nope. it's totally clear :)
19:29:30 <jeblair> gitorious: can disable merge requests.  open source, so can develop enhancements as needed.  supports openid as a consumer, so can SSO with other tools in use (launchpad, jenkins, gerrit).
19:29:33 <jeblair> gitweb: simple, read-only, no collaboration features.
19:30:27 <jeblair> does that suggest anything we should explore further?
19:31:34 <notmyname> jeblair: seems to imply that gitweb wouldn't be sufficient for replacing lp code hosting
19:31:43 <notmyname> (although it is useful for other use cases)
19:33:02 <jeblair> it gives us a place to point to and say "here's where you can browse the code".  i'd sort of characterize it as saying it's the way to go if the project as a whole wants to avoid endorsing a web-based method of collaboration during development.
19:33:08 <jaypipes> notmyname: thought we wanted to steer away from "us" vs. "them"?
19:33:55 <jeblair> people will still use github certainly.  probably more so if we went with gitweb.  but the project would be out of the business of telling people how and why to use it.
19:33:58 <termie> *~-we-~*
19:34:34 <jeblair> oh, and i'm assuming gerrit is performing code rewiew with all of those options, just to be clear.
19:34:46 <jeblair> 'review' even.
19:36:16 <notmyname> jeblair: those reasons for gitweb seem to be great if each project is responsible for its own hosting, etc. but since openstack has chosen to do everything the same way, there is still a need for the collaborative tool, right?
19:37:49 <notmyname> ie, using gitweb doesn't meet the requirements (unless I'm missing something). it would have to be gitweb + something, right? is that something gerrit or would there still be a missing piece?
19:37:51 <termie> so, another reason i'd like github: all of my teams other projects are already on there
19:38:27 <termie> s/teams/team's/
19:38:30 <notmyname> termie: in the same boat. all of the other cloud files stuff (swauth, slogging, language bindings) are all on github as well
19:38:50 <jeblair> gitweb will "host code", and gerrit will handle code reviews and merging, so at a minimum, it seems to meet the requirements for "code hosting".  i think it's the collaborative aspect of github (and perhaps gitorious) that's appealing.
19:39:14 <jaypipes> and how many people work on those projects? 3 or 4 maybe? we're talking about a different type of complexity here...
19:39:19 <mtaylor> I agree with that.
19:39:22 <mtaylor> not jaypipes, jeblair
19:39:34 <mtaylor> I think we have two different things here:
19:39:45 <mtaylor> a) code review/queue management and
19:39:52 <mtaylor> b) from where do people clone
19:40:02 <termie> a) gerrit, b) github
19:40:13 <jaypipes> cool with me.
19:40:15 <bengrue> another reason I like github: it increases visibility into the community from the outside world.
19:40:17 * mtaylor tends to agree with termie there
19:40:36 <notmyname> mtaylor: termie: if the pull request confusion is addressed properly
19:40:40 <mtaylor> as long as the pull request auto-closing-with-instructions hook is acceptable to folks
19:40:49 <jaypipes> jinks.
19:41:00 <heckj> mtaylor: I think it's a pretty good/reasonable solution
19:41:09 <jaypipes> or GitHub becomes open source...
19:41:10 <termie> notmyname: i think that is a pretty easy thing to solve
19:41:11 <bengrue> I like the solution.
19:41:11 <mtaylor> notmyname: yes. I would suggest we start with the auto-close hook, and then if it's an ongoing problem, investigate creating gerrit reviews
19:41:26 <jaypipes> mtaylor: ++
19:41:48 <mtaylor> ok - so I'm going to consider this some sort of agreement :)
19:42:07 * termie looks outside to check for flying pigs
19:42:10 <jeblair> termie pointed me to some code that can do a lot of the pull request work.  i'd be happy to do that.
19:42:20 <bengrue> sweet.
19:42:22 <mtaylor> #agreed continue to mirror gerrit projects to github and put in an auto-closing hook for pull requets
19:42:34 <mtaylor> #action jeblair auto-closing pull request hook
19:42:55 <_0x44> mtaylor: Instead of auto-closing-with-instructions, why don't you make a hook that auto-adds it as a request in gerrit?
19:43:07 <_0x44> mtaylor: And have gerrit auto-close the pull-request after merge?
19:43:17 <termie> _0x44: more complicated, stretch goal
19:43:24 <mtaylor> _0x44: I would like to look in to that as step two ... I just think the instructions one could probably be done in a half an hour or so
19:43:28 <termie> _0x44: the other option is a 4 line script and a cronjob
19:43:28 <jaypipes> _0x44: I think he said above they'd try that at a later time.
19:43:34 <mtaylor> wow.
19:43:55 <termie> don't worry guys, i'll try not to make this agreeing thing a habit
19:44:03 <jaypipes> we know. ;)
19:44:06 <_0x44> termie: A 4 line script will be a "solution" that probably won't get fixed, though.
19:44:10 <mtaylor> quick everybody ... vi or emacs?
19:44:19 <termie> VI
19:44:23 <jaypipes> vi
19:44:25 <termie> fuck
19:44:27 <heckj> vi
19:44:28 <jaypipes> ooh.
19:44:28 <mtaylor> _0x44: we keep todo lists and work on them
19:44:29 <termie> s/fuck/dang/
19:44:29 <mtaylor> vi
19:44:35 <nati_> vi
19:44:36 <_0x44> vi, and bengrue is volunteering to write the second-round hook to auto-integrate gerrit and github.
19:44:42 <jeblair> emacs
19:44:46 <mtaylor> yay!
19:44:46 <termie> jeblair: BOOO
19:44:47 <mtaylor> dissent!
19:44:51 <jaypipes> hehe
19:44:55 <mtaylor> ok- the world is ok again
19:45:26 <jeblair> we also keep scripts in git, and accept patches.
19:45:40 <mtaylor> speaking of ...
19:45:42 <_0x44> bengrue: pipe up so they don't think I'm just volunteering you. :)
19:45:57 <mtaylor> anybody want to write better css for gerrit?
19:45:58 <bengrue> yes, I can write the stretch goal script.
19:46:05 <notmyname> _0x44: now he has to. aren'tyou his boss? ;-)
19:46:13 <bengrue> As long as I have an introduction to gerrit.
19:46:24 <_0x44> notmyname: Yes ;)
19:46:30 <creiht> lol
19:46:37 <bengrue> jmckenty said lat week that I can use 4 hours a week on CI tasks for openstack.
19:46:46 <mtaylor> w00t
19:46:50 <bengrue> So as I come up to speed that'll be more and more useful.
19:46:50 <notmyname> your 2% time?
19:46:52 <heckj> ++
19:47:04 <mtaylor> bengrue: happy to have you help!
19:47:39 <bengrue> I'm still in the learning phases of openstack development, but CI methodology is something I'm a bit more familiar with.
19:47:41 <_0x44> notmyname: We don't work quite 168 hours a week, so it might be a bit more than 2%.
19:47:42 <bengrue> Glad to help.
19:47:46 <mtaylor> bengrue: be sure to bug jeblair or I if you grind to a halt anywhere
19:47:58 <bengrue> ha, good to know.
19:48:28 <bengrue> (lunch has arrived at piston)
19:50:55 <mtaylor> ok - anybody got anything else?
19:51:40 <jaypipes> nope
19:52:08 <mtaylor> great. thanks everybody ... and try not to have your day ruined by us agreeing on something
19:52:12 <mtaylor> #endmeeting