geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject [DISCUSS] Finalizing migration and figuring out our steady state
Date Fri, 08 May 2015 01:02:23 GMT

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

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.

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 or any other tool.

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.


View raw message