On Fri, May 8, 2015 at 4:48 PM, Dan Smith <[email protected]> wrote: >> 2. A typical ASF way for signaling that you would like to >> contribute something is to open up a JIRA and follow up >> with the patch. What about our Github integration? I'd suggest >> the following: anytime a PR comes, a committers who is >> interested in helping to get the patch in opens up a corresponding >> JIRA. That way we can have a central source of truth >> on ASF JIRA while still enabling the workflow. >> > > Seems reasonable. Although we should encourage contributors to submit a > JIRA and include that JIRA with their pull request.
I could see cross-linking going both ways. That said, I don't think we should require submission of PRs. A pure JIRA-based workflow should be just fine. >> 3. If we agree that JIRA is our central information radiator >> for tracking all the contributions to the project AND that >> patches should be attached to a JIRA, then the only question >> I have left is about reviews. I propose that this is the request >> that whoever is providing a review can make of original >> submitter. If the patch is tiny -- it can be reviews as-is. >> If it is large the original submitter could be asked to upload >> it to https://reviews.apache.org or any other tool. >> > > GemFire developers have used reviewboard internally for a while so using > reviews.apache.org should be a fairly easy transition. I would bias towards > just uploading to reviewboard as committer. Great! My only point was that if a proposed change is a few lines in a few files personally I find it the easiest to review the attached patch. > One point I'm not quite clear on what you are proposing - are you > suggesting attaching a patch to the JIRA for every code change? I don't > think there should be much need to attach a patch to a JIRA unless someone > feels like that's how that want to contribute. Between github, reviewboard, > and feature branches generally someone should just be able to point to the > PR. Like I said -- attaching a patch to a JIRA could be the easiest form of a review. You attach a simple few lines of change -- you get a +1, you commit. No fuzz, very simple process. On top of that we need to maintain permanent record of patches and how they were discussed (especially complex ones). Having them attached to a JIRA helps tremendously in cases when you're debugging something, do a git blame, see a JIRA ID and start unraveling the discussion that led to the change. At that point JIRA MUST have a track record of patch evolution. That's why GH can NOT be used -- the discussion can't be archived and gets removed with the repo. If you want to use permanent ASF reviewboard links instead of attaching patches to the JIRA that may be fine, but I'd really like to hear what other think. Long story short -- whatever it is -- it has to guarantee a permanent track record that can be referenced from JIRA. >> 4. Finally, the question of committing the change. I'll chime >> in on a separate thread that you guys have already created, >> but for now (given that there's a final code drop coming soon) >> I'd like to propose that Dan, William and Anthony should >> be required to give any patch an explicit +1 before it gets >> committed. This is ABSOLUTELY NOT a suggestion for >> having gatekeepers. This is just a suggestion of what we >> do between now and when the final code drop comes. Meantime >> we'll have a separate discussion on how roadmap for the >> project gets maintained and how anything that doesn't require >> studying code base for a few month could be committed to >> the project. >> > > That's fine, but I think we're also watching the list and so will chime in > if a change looks problematic in any case. I think the main thing is just > to not change the source code on develop until we get the tests. Things > like working on the website content I'm not worried about. Yup. And that's why as a stop-gap measure I'll be relying on you William and Anthony to make a call of what may be disruptive for you code drop vs. not. Speaking of which, I'd appreciate your feedback on GEODE-19 ;-) Thanks, Roman.
