[02:09:26] --- manfred furuholmen has become available [03:40:54] --- SecureEndpoints has left: Replaced by new connection [05:07:00] --- manfred furuholmen has left [05:46:36] --- SecureEndpoints has become available [06:00:09] --- manfred furuholmen has become available [06:21:46] simon - do you have a sample workflow somewhere to show what you're thinking wrt gerrit? [06:23:07] Essentially, gerrit defines the workflow. [06:24:33] Developer uploads patch into gerrit. Other developers, and gatekeepers review patch and submit comments to gerrit. Automated build system builds (and possibly tests) patch, and reports back into gerrit. [06:24:58] Once suitable builds/test results are obtained, gatekeeper hits 'apply patch' button, and gerrit applies the patch to the repository. [06:25:40] so you're thinking the 'standard' android gerrit workflow? [06:26:21] Yes. That's what we discussed at Google. [06:26:51] we never explicitly published the details and he wasn't there for it [06:27:37] Of course. That was a meant as a "that's what was discussed last time it was discussed, but no real decisions were made" - not as a "don't you know this already" [06:28:04] We'd also discussed making gerrit populate RT with a ticket per applied patch containing the review comments. [06:28:30] I don't know how relevant that will be if we use gerrit2 (which lets us run the database) rather than gerrit (where the database is embedded into Google AppEngine) [06:28:32] or, if rt is replaced by something, populating the replacement. [06:28:38] --- reuteras has left [06:29:09] well, the problem would be introducing too many places to force people to look for information about open problems [06:29:12] my questions are around thoughts on project roles and project layout: e.g., http://source.android.com/project clearly defines some roles w/in the project overall. What are we thinking the analogy of that is for openafs? [06:29:27] --- reuteras has become available [06:30:20] and, for example, the project layout breaks things into smaller pieces, so delegation of reviewing can be done more easily. e.g., http://source.android.com/projects [06:30:50] I'm thinking that gerrit wouldn't drive any governance changes. [06:30:52] as an example, Russ might want to delegate doc signoff to edgester. [06:30:54] ah, ok. [06:31:14] Governance changes might come, but I don't think they should be driven by the tools we use. [06:31:30] I thought one of the major drivers of using git was to facilitate that. [06:31:46] not necessarily to require it, but to be able to facilitate it where useful. [06:32:02] Git (and gerrit and ...) open up more options in terms of governance. [06:32:07] * stevenjenkins nods. [06:32:24] But my view is that we should deploy them in the current system. [06:32:43] I don't quite grok that sentence. [06:33:03] We shouldn't make governance changes just because we have shiny new tools that let us do so. [06:33:08] using new tools does not require any changes to people utilization [06:33:14] ie, 'them' refers to governance changes & 'current system' means cvs? or does 'them' mean 'git+gerrit' and 'current system' mean the current governance structure? [06:33:15] it allows it. it does not require it [06:33:36] ==shadow. He said it better ... [06:33:51] what's the crux of the line of questioning here? [06:34:14] From a gerrit perspective, I think anyone should be able to review. Only gatekeepers can hit the submit button. They should attach weight to the reviews based on their opinions of the people performing them. [06:34:27] I'll cut-and-paste my prev question..my questions are around thoughts on project roles and project layout: e.g., http://source.android.com/project clearly defines some roles w/in the project overall. What are we thinking the analogy of that is for openafs? [06:35:04] cutting and pasting your question, which i read, does not tell me why you're asking it, which is the thing i am asking. [06:35:27] Okay. Using the terms in that document. Androids "anyone" and "verifiers" are everyone. "Approvers" and "Project Leads" are the gatekeepers. [06:36:04] at least until other changes are made, yes [06:37:48] I think it is a good idea to leverage the conversion as an opportunity to get more people involved in the process, perhaps not immediately (ie, it's easier to keep the current governance structure in place so as to have fewer moving parts), though. But by breaking things into projects, it could be a good way to get people involved at a level that they can be helpful. My canonical example is edgester helping Russ, but I suspect there are others that would be willing to help review certain other components. [06:38:14] Helping review is, I think, covered under the current arrangements. [06:38:32] ? [06:38:56] the difference is the tools in use on't make doing it with the current arrangement useful [06:38:58] Derrick and Jeff regularly post received patches and solicit review comments on them. [06:39:15] and occasionally someone looks at one [06:39:27] sxw - right, but that requires derrick and jeff to seek review, rather than things be sent to certain people automatically. [06:39:37] Yes. [06:40:00] um. no. not really. [06:40:15] it requires us to seek review because no one's falling over themselves to do it. [06:40:22] The political stickler is that our _current_ system requires that only gatekeepers have commit access. Changes to that require more community discussion and consensus than just deploying a new tool set. [06:40:32] go read rt. i don't have to ask you. you already can. [06:41:04] To be fair, rt doesn't make it especially easy to see all of the tickets that contain patches requiring review. That's one thing that better tools can help with. [06:41:08] i have to ask for review because when i get to it as often as not it's me, and the person who submitted it, and that's all the eyes that have seen it [06:41:12] agreed [06:41:15] I'm not suggesting (necessarily) that additional people have commit access, but gerrit gives a mechanism so that the src can be broken into subprojects so that it's easier for people to look at the pieces they are interested in. [06:41:25] oh. absolutely. [06:41:37] the tools definitely improve the ability to collect and manage input [06:41:44] Yes. I completely can't see any harm in allowing people to get email when patches are submitted for stuff they care about. [06:41:49] which is critical to quality output [06:41:56] shadow - rt? yes, but there is no 'push' from RT to individuals other than gatekeepers (as currently configured). [06:42:11] there's not push to the gatekeepers either [06:42:19] sxw - that's what I'm thinking. [06:42:19] What I think is a bad idea is making that set of people selectable in some way. Anyone that wants to should be able to review, and their comments should be weighted according to their standing. [06:42:20] i don't get mail for a new ticket. i go look at rt. [06:42:34] ++sxw [06:42:48] shadow - really? RT isn't set up to mail on new tickets? [06:42:49] good, then you've just abandoned your own position :) [06:42:53] nope. [06:42:55] that's....painful. [06:43:07] why do i want mail? [06:43:10] shadow - I don't grok the 'abandoned your own position'. [06:43:28] --- reuteras has left [06:43:43] simon said anyone could comment, you agreed. "anyone" was not one of the assigned roles you seemed to be advocating a moment ago. [06:43:51] *anyone* can already comment. [06:43:55] perhaps you don't want mail, but I find mail a good way to receive notification of something. I can choose to respond or not, but at least I know something has changed. [06:43:59] read the crap and comment. [06:44:15] --- reuteras has become available [06:44:20] It's all about personal workflow, I guess. [06:44:26] oh. i'm not arguing the tools should not provide a way to get notification. just that you getting notification should not force me to [06:44:40] shadow - I agree with that. [06:44:43] nor should you getting notification be contingent on you being some blessed subproject member [06:45:03] if you want to review, review. if you want to be notified of something, configure yourself to be. [06:45:06] Very much so. We need fewer barriers to participation, not more. [06:45:14] agreed. [06:45:44] this is not actually any different from today, in the "policy" manner. it's just that the tools don't actually adequately support the policy [06:45:54] Once we've got git, my intention was to write a document about gerrit, and how we could go about using it. [06:46:12] But, I'm on honeymoon from 3 Fed to 15 Mar ... [06:46:42] i am still pushing the patches since google into a git tree. when it's done, hopefully this week, the whole tree is going on the stanford machine. i don't know, though, if the tools on hat machine are ready to support it adequately. [06:47:10] sxw - I'd be happy to help with said document, give feedback, etc. [06:47:18] Okay. I think that the gerrit2 timescales may also affect us. [06:47:32] I don't see any point in going live with gerrit, when gerrit2 is so nearly ready. [06:47:43] yes, I've been keeping an eye on the gerrit2 stuff as well..as I think it would be good to use gerrit2 since we wouldn't be tied to google apps. [06:47:57] stevenjenkins: Indeed. [06:48:11] Also, I think that the GAE gerrit is likely to become unsupported as soon as gerrit2 matures. [06:48:26] can't blame them for that [06:49:04] Nope. But all of that means that there's not much point in turning on gerrit, just to have to migrate over in a few months time. [06:51:44] shadow: While we're talking governance, what's the progress with the foundation? [06:52:03] sxw - had the cvs -> git migration not taken ~8 months or so, I'd agree with you more strongly. [06:52:20] bug me when i've had more time to have finished edits. holidays happened. [06:52:26] as is, I see the point and agree, but I also wonder if it would at least be good to put together some intermediate git-only notes for people. [06:52:49] shadow: Sure. I wasn't sure if there were more edits to happen. [06:52:55] --- sxw has become available [06:52:55] when i know what the remote access looks like i can put together git notes. [06:53:02] --- sxw has left [06:53:06] shadow - cool. [06:53:32] it was in the plan. basically a "developing openafs with git" faq [06:53:37] Let's see where we (and gerrit) are when the git conversions done. It would be nice to be able to go live with both. [06:54:13] (gerrit uses a tool on top of git, and in effect requires that each patch be developed in its own branch) [06:54:13] sounds good to me. [06:54:48] developed, or simply managed by gerrit as? [06:55:03] like, once i submit it, i thought gerrit didn't care how i made it. [06:55:11] gerrit gets a diff and does its thing. [06:55:13] Gerrit doesn't care how you made it. [06:55:31] But if you want to use repo to handle the submission, then you need to use repo throughout the process. [06:55:39] sure [06:56:10] Gerrit also doesn't (currently) have a nice tool that just takes a patch. [06:57:00] The process to submit a patch is 'repo start; apply patch; repo upload' [06:57:26] Using repo has the advantage that it can maintain dependencies between patches, which is good for complex changes. [07:01:22] --- dmontuori has become available [07:15:21] --- reuteras has left [07:28:13] --- Simon Wilkinson has left [07:28:14] --- Simon Wilkinson has become available [07:32:49] --- Simon Wilkinson has left [07:36:19] --- Simon Wilkinson has become available [07:36:44] --- Simon Wilkinson has left [07:37:53] --- Simon Wilkinson has become available [08:09:01] --- dev-zero@jabber.org has left [08:54:01] --- matt has become available [08:54:21] --- Claudio Bisegni has become available [09:03:55] --- Claudio Bisegni has left [09:27:08] --- Russ has become available [09:55:15] --- dev-zero@jabber.org has become available [09:59:26] --- manfred furuholmen has left [10:59:59] --- mmeffie has become available [12:20:27] --- dlc has left [12:20:54] --- dlc has become available [14:39:02] --- manfred furuholmen has become available [14:41:41] --- dmontuori has left [14:41:47] --- manfred furuholmen has left [14:59:11] --- manfred furuholmen has become available [15:12:43] --- manfred furuholmen has left [17:05:03] --- edgester has become available [18:44:13] --- matt has left [18:55:00] --- edgester has left [22:10:35] --- Russ has left: Disconnected [23:22:30] --- reuteras has become available [23:49:53] --- manfred furuholmen has become available [23:59:57] --- dev-zero@jabber.org has left