What would this Git repos be for?
On 2 April 2013 19:59, Benoit Chesneau <bchesn...@gmail.com> wrote: > Cool, > > Thanks Randall & Noah for the feedback. I think we are all OK to start > to work on that then. Randall can you provide a link for the tool you > mention in the cassandra project? I would be interested by them. > > > To start all the process I will open a git repo somewhere so we can > start to hack all together. Not until the end of the week i'm actually > busy at work. > > - benoît > > > On Sat, Mar 30, 2013 at 2:03 PM, Noah Slater <nsla...@apache.org> wrote: > > Your proposal looks good Benoit. I'd be happy to see us work towards > this. > > > > > > On 29 March 2013 22:17, Randall Leeds <randall.le...@gmail.com> wrote: > > > >> On Thu, Mar 28, 2013 at 3:12 AM, Benoit Chesneau <bchesn...@gmail.com> > >> wrote: > >> > I should have posted it since a while but was side tracked by work and > >> > travel. Anyway here is a workflow I had in mind since a long time. > It's > >> not > >> > here to forbid the use of Github PR or system like one. On the > contrary > >> it is > >> > trying to find a way to work with them while keeping the @dev > >> mailing-list as > >> > the first citizen. This is just a proposal. If there are any legal or > >> > technical constraints that seem to stop it then let me know in > response > >> to > >> > this thread as well. > >> > > >> > Git has been designed from the ground to work with email and many > >> commands > >> > inside git are just here for that: git-format-patch(1), git-apply(1), > >> git-am(1), > >> > git-send-email(1). It's really easy to send a patch via email and test > >> it on > >> > any source code. I would like to use this feature as the core > component > >> of > >> > our workflow. > >> > >> Yes. I love these. It is my preferred workflow. I even have tools that > >> I snagged from the Cassandra project for sending patche to JIRA from > >> the command line using these tools. I believe I linked them somewhere > >> on the wiki, but I can document this better if other people have an > >> interest. > >> > >> > > >> > Today we are using 2 main tools in the Apache CouchDB project: Jida > and > >> > the mailing lists. We also have a github mirror. I didn't have the > time > >> to > >> > test the review tool we have, and if someone did I would be happy to > >> have a > >> > feedback on its usage. > >> > > >> > So what I propose as main workflow is this one: > >> > > >> > - The main git repo centralize features & fixes which have a ticket in > >> Jira, > >> > also master & release branches. We probably need a develop branch > for > >> C-I > >> > where fix/features branches should land before going in master or > >> releases > >> > branches but that's another topic. > >> > - Patches should be sent and discussed on the mailing-list. So anyone > >> susbcribed > >> > on the mailing-list can comment them and update the thread with new > >> patches. > >> > - Once a patch has been reviewed or lazily reviewed (ie. after a time, > >> noone > >> > responded), a developer commit it on a branch on the main repo. > >> > - After a final approval the patch will land in one of the main > branches > >> > (release, master, develop). > >> > > >> > This workflow allows us to keep git decentralized and let small > groups or > >> > individials to manage the code outside apache while keeping main > >> discussions > >> > for patch integration on the ml. > >> > >> +1. Committers have been using branches for this, but it's good to > >> have a workflow where others can have branches. The email (or) JIRA > >> workflow, when it's well tooled with git, gives everyone this ability > >> by making it easy to contribute what they've done in their local > >> branches. Github is merely a place to post those branches, but if the > >> patches contained therein can hit us another way, like JIRA or ML, > >> that's a win. > >> > >> > > >> > What about JIRA: > >> > ---------------- > >> > > >> > - If a patch is answering to an issue in JIRA, it *must* link to it in > >> using a > >> > syntax > >> > - Each response could be eventually appended to the JIRA ticket, but > >> maybe we > >> > could just link the mailing list thread? > >> > >> Getting COUCHDB-XXXX mentions in the ML linked like trackbacks in JIRA > >> would be outstanding. If we also had Github pull requests going to the > >> dev list people could even transitively contribute to JIRA via pull > >> requests. > >> > >> > > >> > What about GITHUB Pull Requests: > >> > -------------------------------- > >> > > >> > Since we have a mirror on github, I'm kinda agree with Noah that we > can't > >> > really forbid the use of PR. Especially since most want it. > >> > > >> > In my understanding and reading the Github API [1], PRs are some kind > of > >> > patches. As a patch they could be hooked to the ML. > >> > > >> > The proposed workflow for PR is: > >> > > >> > 1. When creating a PR a thread is created on the ML > >> > 2. Each new patch to the PR is sent to the ML > >> > 3. Any new comment on the PR is sent to the ML > >> > 4. Any comment on the ML is sent to the PR. We could find a syntax as > >> well to > >> > annotate a line just like github does. > >> > 5. Any patches sent to this ml thread is also added to the PR. > >> > >> Perfect. This is what I've been thinking, too. I suspect everyone > >> would find this a fantastic situation if we can work it technically. > >> > >> > I reckon this workflow imply some work to handle PR notifications or > Jira > >> > integration, but at the end I think it's a win-win solution preserving > >> our > >> > neutrality while opening ourself to others. I'm happy to help on that > >> work. I > >> > will probably also need the help of @davisp since he knows more about > the > >> > Apache Foundation internals than me. > >> > >> I'm also happy to help. If we lay out the individual scripts needed I > >> can work on some of them. > >> > >> > > >> > Anyway let me know what you think about it. > >> > > >> > - benoît > >> > >> I think it's great. Thanks for bringing this thread. > >> > > > > > > > > -- > > NS > -- NS
