13:32:48 <heidie> #startmeeting
13:32:49 <Services> Meeting started Mon Sep 15 13:32:48 2014 UTC.  The chair is heidie. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:32:49 <Services> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:32:51 <heidie> :-)
13:34:01 <heidie> #topic Current Status
13:34:06 <heidie> What have folks been doing?
13:34:30 <stoney> #info groomed tickets; not planning to do anything else (promise); no roadblocks
13:34:32 <heidie> #info Stoney and I pushed the latest version of the gnome3-wip branch back to GNOME
13:34:53 <heidie> kevin-brown: Anything new?
13:35:33 <kevin-brown> #Info I've tested MouseTrap on Windows 7, but didn't get that far as my webcam didn't work
13:36:13 <heidie> Was the problem in the webcam itself?
13:36:16 <heidie> Or something else?
13:36:28 <kevin-brown> It's a problem on my side, not MouseTrap's
13:36:55 <heidie> Ah, OK.
13:36:57 <heidie> :-)
13:37:08 <heidie> Any other roadblocks?
13:38:12 <heidie> OK, taking that as a "no"
13:38:20 <heidie> #topic Future Plans
13:38:37 <heidie> #info CS 490 students should have MT installed by Tuesday.
13:38:39 <stoney> # no short range plans
13:38:47 <stoney> #info no short range plans
13:39:10 <heidie> #info And we'll start working on bugs, specifically migrating OpenCV
13:39:23 <kevin-brown> #info I'm going to take another shot at getting the webcam to work in Windows
13:39:34 <heidie> #info There is a group of three students from Miami of Ohio who may also work on MouseTrap
13:39:55 <heidie> #info These students would be working through the spring as well. They're doing a senior project.
13:42:16 <heidie> OK, so shall we talk about github versus bugzilla?
13:42:25 <stoney> sure… topic change?
13:42:34 <heidie> #topic Development Location
13:42:41 <heidie> Is that what you meant?
13:42:46 <stoney> yup :)
13:43:20 <heidie> OK
13:43:54 <heidie> Assuming that everyone is up on the conversation on the mousetrap list, the main question is how to we develop a GNOME module in a way that is workable?
13:44:32 <heidie> hmmm, let's start with a basic question.
13:44:58 <heidie> Where do people stand with respect to keeping MT as a GNOME module?
13:45:10 <stoney> it is a GNOME module
13:45:35 <heidie> Right, do we want for our group to continue to develop as a GNOME module?
13:45:39 <heidie> I'm throwing ideas out.
13:46:01 <kevin-brown> My thoughts are that it should stay a GNOME module
13:46:07 <heidie> And wanting to see what folks are thinking.
13:46:08 <stoney> ditto
13:46:23 <stoney> it should stay GNOME's
13:46:27 <heidie> OK, so it is a GNOME module.
13:46:52 <heidie> So as per Jo*nie, we cannot have folks submitting bug reports to Github.
13:47:16 <stoney> who are “folks” and what is a “bug report” ?
13:47:25 <heidie> Ah, right, good questions.
13:47:56 <stoney> can I ask perhaps a more direct question?
13:48:02 <heidie> The big picture is that when MT is released with GNOME, we'll get users.  And these users will bring in developers (hopefully).
13:48:04 <heidie> Sure!
13:48:11 <stoney> what do you think needs to change about what we are doing to comply with GNOME?
13:49:08 <stoney> you = we
13:49:12 <heidie> I think that we need to be a bit more transparent.
13:49:16 <heidie> For example
13:49:23 <stoney> what isn’t transparent?
13:49:45 <heidie> I think that we need to have the bugs about upgrading OpenCV on Bugzilla
13:50:12 <heidie> More generally, I think that we need to show the current status of development on Bugzilla as a communication mechanism.
13:50:38 <stoney> ok… so more visible through bugzilla
13:50:40 <heidie> We need users to be able to see what we are working on and potential developers to be able to pick up something and help.
13:50:43 <heidie> Yes, right.
13:51:14 * heidie thinks there is an interesting application here that automatically ensures integrity of bugs listed on both sites....
13:51:45 <heidie> Because we may have developers coming in from the GNOME community, Bugzilla needs to be a portal for that.
13:51:52 <stoney> kevin and I have been talking about synching…. but GNOME’s bugzilla does not expose an API for doing that
13:51:58 <kevin-brown> stoney and I talked about mirroring them before
13:52:02 <heidie> Ah, is there an API?
13:52:08 <kevin-brown> Right, we have a missing API issue
13:52:14 <stoney> yes… but not installed in GNOME
13:52:20 <stoney> GNOME’s bugzilla
13:52:25 <heidie> Ah, so this is something that we might be able to request.
13:52:50 <heidie> kevin-brown: Can you do a post on the list about the exact API and where to get it?
13:52:59 <heidie> kevin-brown: Doesn't have to be now.
13:53:06 <kevin-brown> Most likely, I never checked to see if it supported Bugzilla 3.0
13:53:09 <kevin-brown> heidie: Sure :)
13:53:13 <heidie> OK, thanks.
13:54:07 <heidie> So step 1 is to see if we can get parity between github and bugzilla
13:54:40 <heidie> What about when we want to include an enhancement in the code.
13:54:42 <heidie> ?
13:55:10 <heidie> The process on Bugzilla is patches, on github it is simply branch and merge. Both followed by a test and push.
13:55:47 <heidie> Do we need to make patches for code developed on github? Or is the ability to rollback changes in git sufficient?
13:55:47 <kevin-brown> Bugzilla has built-in code review, as does GitHub. Both of them support patch sets, GitHub also supports branches
13:56:18 <stoney> Kevin convinced me that we can to pulls and pushes using bugzilla too… but I think that is a maintainer decision (i.e., you, as far as how you want to handle contributions)
13:56:37 <heidie> Ah, OK. So this becomes a process question?
13:56:53 <heidie> Stoney, you have admin rights to Bugzilla, yes?
13:57:14 <stoney> bugzilla yes… but not commit privileges to GNOME repo
13:57:40 <stoney> so, upstreaming is all you at the moment :)
13:58:07 <heidie> Ah, right. So I'm the bottleneck.
13:58:14 <stoney> which I think is fine, and makes things clear, and prevents awkward issues like what happened with the tickets over the weekend :
13:58:15 <stoney> :)
13:58:21 <heidie> Does it make sense for stoney to get commit permission?
13:58:26 <heidie> :-) Got it.
13:58:51 <heidie> So what you're saying is that I'll need to be more proactive in committing changes.
13:58:55 <stoney> so… to patch or not to patch… can we talk about that for a second?
13:58:59 <heidie> Sure.
13:59:28 * heidie thinks we need a summary of our process once we've worked the kinks out.
13:59:42 <stoney> when we do patch to commit… usuallly this becomes squash your commits into a single patch
13:59:51 <heidie> Yes
13:59:52 <stoney> when we do that, we lose multiple authorship
14:00:00 <stoney> which is bad for student collaboration
14:00:09 <stoney> or team development
14:00:22 <heidie> Ye, right.
14:00:56 <stoney> so, I’m not in favor of a single commit contribution type of approach… unless
14:01:21 <stoney> we are making all of our tickets so small that anyone can make a quick commit
14:01:22 <heidie> Small commits?
14:01:26 <heidie> Right.
14:01:27 <stoney> which is possible
14:01:34 <stoney> but hard to coordinate a larger change
14:01:38 <heidie> Yes, right.
14:01:53 <stoney> can I make another suggestion
14:01:57 <heidie> So is it possible to have two ways to push to git.gnome?
14:02:02 <stoney> (that kevin-brown will probably hate)
14:02:04 <stoney> :)
14:02:19 <heidie> One through merging to my github account and a second through Bugzilla?
14:02:26 <heidie> :-)
14:03:06 <stoney> well… kevin-brown has outlined (somewhere) how to use bugzlilla with github pull requests, pulls, and pushes and still being highly visible
14:03:20 * heidie looks
14:03:22 <stoney> (that wasn’t the suggestion I’d like to make… just addressing your comment)
14:03:34 <stoney> kevin-brown: do you have that handy?
14:03:46 <stoney> or was that in your email?
14:04:02 * stoney having trouble tracking all his communication
14:04:03 <kevin-brown> Most likely that was in the email, assuming you are referring to how Django does it
14:04:13 <stoney> exactly
14:04:13 <stoney> that
14:04:35 <stoney> although… with the modification of not a patch
14:04:44 <stoney> or is that possible?
14:05:04 <kevin-brown> With GitHub, that'd be possible
14:05:11 <kevin-brown> (I'm getting all the links together right now)
14:05:42 <kevin-brown> Django workflow, as explained by me: https://gist.github.com/kevin-brown/13958a4d5dafc2b06db8#django
14:05:42 <kevin-brown> Example ticket (with pull request): https://code.djangoproject.com/ticket/23452
14:05:45 <stoney> and heidie, back to your question… even if the pull-push works (with good crossreferencing) you could still do patches too
14:06:11 <stoney> so we could support both
14:06:28 <stoney> but that places a bigger technical burden on you
14:06:30 <heidie> Yes, right.
14:06:43 <heidie> But I'm not as worried about that.
14:06:52 <stoney> ok :)
14:07:11 <stoney> so here was the suggestion I’d like to make...
14:07:14 <heidie> Especially if you and I can continue to keep doing triage occassionally like we did last year?
14:07:33 <heidie> #link  https://gist.github.com/kevin-brown/13958a4d5dafc2b06db8#django
14:07:38 <stoney> (putting pause in his suggestion)
14:07:50 <heidie> #link https://code.djangoproject.com/ticket/23452
14:08:02 * stoney looking
14:08:43 <stoney> ah ok
14:10:28 <heidie> So on the github side, we could either do a patch or a pull request, yes?
14:11:05 <stoney> well both
14:11:13 <stoney> when you do the pull request
14:11:15 <stoney> it is a patch
14:11:27 <heidie> Oh, got it.
14:11:28 <stoney> just add .patch to the end of the url
14:11:37 <heidie> Ah, OK.
14:12:05 <stoney> but if you could also add a remote, pull changes from their branch, and push
14:12:15 <heidie> Oh, right!
14:12:23 <stoney> that would preserve multiple authors and not require squashing
14:12:47 <heidie> I already have a remote to github from my master.
14:12:50 <heidie> Right.
14:13:15 <stoney> right… but what about if others use other github accounts and want to contribute?
14:13:25 <heidie> Ummm, right...
14:13:42 <stoney> using the model I just suggested, you’d have to add their remote, pull, push
14:13:49 <heidie> Well, nothing stopping them from going through Bugzilla
14:14:09 <stoney> you mean with patche?
14:14:11 <heidie> Right, got it.
14:14:13 <heidie> Yes.
14:14:32 <stoney> no… but say this other school uses a different github repo to do team development…
14:14:41 <heidie> I suppose though that they'll find the github MouseTrap
14:14:43 <stoney> they may not want to squash
14:14:49 <heidie> Oh, right.
14:15:14 <heidie> Well, can we put attribution in the commit comments? Not an ideal solution.
14:15:41 <heidie> Or are we talking about small bugs again. Keeping issues to small enough sizes for students to work on.
14:15:56 <stoney> (btw… there is a command-line tool called hub that wraps git and allows you to work more smoothly with github: this might make things like we’re talking about easier: https://github.com/github/hub)
14:16:49 <stoney> I would like to support the no-squash policy if we can
14:17:48 <stoney> (unless there is some great reason other than the technical one we are discussing for requiring squash)
14:17:53 <heidie> #link https://github.com/github/hub
14:18:00 <stoney> right, sorry :)
14:18:11 <heidie> Right, I definitely want students to have their work visible.
14:18:32 <stoney> we could ask Linus to add multiple authors to a commit :)
14:18:33 <heidie> #info there is a command-line tool called hub that wraps git and allows you to work more smoothly with github
14:18:41 <heidie> Right!
14:18:51 <heidie> Let me know what he says, would you? ;-)
14:19:00 <stoney> I’m sure someone has asked
14:19:08 <heidie> Right! Likely so
14:19:32 <heidie> Just to be clear stoney, you're saying keep the bugs small to avoid squashing
14:19:34 * stoney looking for the issue tracker for git
14:19:35 <heidie> ?
14:19:43 <stoney> yes and no
14:19:53 <kevin-brown> I think Git is all over mailing lists, no?
14:20:32 <stoney> smaller tickets are great… but I don’t think always reasonable
14:20:57 <stoney> I suspect teams are going to manage themselves, using different processes and strategies for breaking down the work
14:21:17 <stoney> so I think it’s import to support no-squash contributions from teams
14:21:18 <heidie> YEs, right.
14:21:32 <stoney> but smaller tickets are a great goal
14:21:35 <heidie> Yes, right, I'm thinking that students will have a record of their work on github.
14:21:43 <heidie> So yes, smaller tickets.
14:21:53 * heidie thinks she needs to go at 10:30...
14:22:14 * kevin-brown also needs to get on the road soon
14:22:23 <kwurst> stoney: I think it’s this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880
14:22:39 <stoney> thanks kwurst !
14:23:11 <heidie> :-)
14:23:22 <heidie> Have we reached consensus?
14:23:29 <heidie> Can we outline it?
14:24:00 <stoney> Well, I don’t think we’ve addressed all the issues
14:24:07 <kevin-brown> ^
14:24:07 <heidie> ?
14:24:09 <stoney> but I think we have a general direction
14:24:29 <stoney> well… are we turning off the issue tracker on GitHub
14:24:30 <stoney> ?
14:24:44 <kevin-brown> Though I think that if we start outlining it, the issues can be addressed easier
14:24:49 <stoney> if not… how do we handle bugs reported to GitHub’s tracker?
14:24:57 <stoney> true kwurst
14:25:02 <stoney> that should have been kevin-brown
14:25:03 <stoney> :)
14:25:10 <stoney> tab completion got the better of me
14:25:19 <kevin-brown> I believe the GitHub tracker issue hinges on the API, which I need to send a post about :)
14:25:21 <heidie> Umm, I thought that we were going to synchronize bugs using the API?
14:25:26 <heidie> Right.
14:25:37 <stoney> kevin-brown: I disagree… I don’t think it hinges on it :)
14:25:50 <heidie> What do you think it hinges on stoney ?
14:25:56 <stoney> I don’t
14:26:03 <kevin-brown> Alright, the API makes it easier
14:26:05 <stoney> if I fork gnome’s MT
14:26:11 <stoney> and start developing in a team
14:26:43 <stoney> I’m may use whatever issue tracker I need/want to help coordinate my team’s efforts
14:26:50 <stoney> so that was my big suggestion
14:27:02 <heidie> Ah, got it.
14:27:04 <stoney> we should consider the issue tracker on GitHub as project management tool
14:27:11 <stoney> bugs should go to bugzilla
14:27:18 <stoney> feature requests to bugzilla
14:27:22 <heidie> So you're suggesting using Bugzilla to keep track of bugs and make develpoment in the large, visible.
14:27:32 <stoney> yes
14:27:36 <heidie> Then students can "claim" a bug and work in the small on github
14:27:37 <heidie> Yes?
14:27:41 <stoney> and to support he gnome user/developer community
14:27:45 <stoney> yes
14:27:46 <heidie> Yes, good.
14:27:57 <stoney> they would put a pointer to the github effort in the bugzilla ticket
14:28:21 <heidie> And contributing back uses patches to Bugzill?
14:28:33 <stoney> no because of the squash issue
14:28:41 <stoney> at least not for teams
14:29:28 <heidie> Ah, right. So two approaches for contributing back: Bugzilla for individual contributions and team contributions where attirbution doesn't matter, and github for teams where attribution matters?
14:29:37 <stoney> yup
14:29:55 <heidie> Got it!
14:30:13 <stoney> and I’m sure the silence from kevin-brown is because he thinks I’m insane :)
14:30:18 <heidie> Super! :-)
14:30:20 <kevin-brown> Now, does someone want to start documenting this?
14:30:24 <kevin-brown> :)
14:30:29 <stoney> I can’t today
14:30:30 <heidie> Right!
14:30:32 <stoney> maybe some later
14:30:43 <stoney> but we need a collaborative place to work on this
14:30:48 <stoney> titan pad?
14:30:59 <heidie> Yes, good idea.
14:31:03 <kevin-brown> Sure
14:31:09 * stoney starting one
14:31:20 <heidie> :-)
14:31:23 <heidie> You beat me!
14:31:30 <stoney> (one second… slow)
14:31:34 <heidie> :-)
14:31:44 <heidie> Right. I'm having trouble connecting. Might be down.
14:31:59 <stoney> #link https://titanpad.com/mtworkflow
14:32:31 <kevin-brown> Perfect, now should this end up being an outline of the contribution flow or a general contribution guide?
14:32:55 <stoney> yup
14:33:01 <heidie> :-)
14:33:21 <heidie> Right, I need to go.  Let's get information in there and we can work on it.
14:33:23 <heidie> Sorry!
14:33:29 <heidie> Gotta run....
14:33:30 <stoney> kevin-brown:  maybe paste in the closest approximation of what we are talking about from your stuff
14:33:32 <stoney> bye
14:33:35 <stoney> end meeting?
14:33:41 <heidie> Remember that this will end the meeting.
14:33:44 <heidie> #endmeeting