> 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. > > 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. 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. > > 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.
