On Thu, May 7, 2015 at 6:02 PM, Roman Shaposhnik <[email protected]> wrote:
> Hi! > > with all the major bits of infrastructure migrated and > almost all of the initial committers now having access > to ASF accounts I'd like to open up a discussion for > getting us into a state when we understand what's > the current process for accepting new code into > the project. Selfishly, I need just as much consensus > on the process as is required for me to push my stuff in ;-) > > What follows is the list of questions I have compiled as > somebody who, for the past week, had various itches > to scratch around Geode and didn't know how to proceed. > I'm also providing a few opinions, but only as a starting > point for a broader discussion. > > 1. Our website. Currently http://geode.incubator.apache.org > doesn't have any content. Two questions that we need to > answer are: > 1.1. What tool will we use to create html > 1.2. How the source code for the website is going to be > managed. > Personally, I'd be pushing really hard to manage a website > as part of the repository so I can just run: gradle site and > not worry about much else > +1 for that and I'd suggest to have a branch (which we already have named asf-site) for hosting the website source. Then as part of the release process it would be required to update the website as well. A Jira component named "website" would hold all the tickets related to that. > > 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. > +1 here but we just need to make sure the GitHub integration happens and that when we commit/accept the PR's they're closed at GH. Also what about comments ? Is there any integration about that so when comments happens in one side they make to the other ? (Jira - GH / GH - Jira) > > 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. > +1 > > 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. > > Thanks, > Roman. > -- William Markito Oliveira
