I didn't know about that one. But yes probably!
On Tue, Apr 2, 2013 at 9:26 PM, Noah Slater <[email protected]> wrote: > https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git > > > On 2 April 2013 20:08, Benoit Chesneau <[email protected]> wrote: > >> On Tue, Apr 2, 2013 at 9:06 PM, Noah Slater <[email protected]> wrote: >> > What would this Git repos be for? >> > >> >> to start the work on some scripts. Can also be done somewhere in the >> repo we already have? What would it be the best according to you? >> >> - benoît >> > >> > On 2 April 2013 19:59, Benoit Chesneau <[email protected]> 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 <[email protected]> >> wrote: >> >> > Your proposal looks good Benoit. I'd be happy to see us work towards >> >> this. >> >> > >> >> > >> >> > On 29 March 2013 22:17, Randall Leeds <[email protected]> >> wrote: >> >> > >> >> >> On Thu, Mar 28, 2013 at 3:12 AM, Benoit Chesneau < >> [email protected]> >> >> >> 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 >> > > > > -- > NS
