All, Now that we have our code up it is important to establish a process around git in particular. A general consensus in the thread appears to be that gitflow workflow is a reasonable option.
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow To that end I've added a develop branch off of master from which features can be built. As we converge toward a release then we'll address/introduce some of the other aspects of gitflow. Please discuss/comment if there are views that we should be taking another path. Thanks Joe On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <[email protected]> wrote: > On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <[email protected]> > wrote: > > Hi Adam, > > > > one remarks about this: > > > > On 28/11/14 18:07, Adam Taft wrote: > >> > >> Knowing how we work today, if it were me, I would suggest using the > above > >> workflow combined with the "forking workflow" to guard access to the > >> production release (master) branches. A very small subset of the > >> incubator's commiters should have the ability to merge the "develop" > >> branch > >> down to a master "release" branch. > > > > > > Suck workflow is not in place in ASF. On the one hand, the current git > > infrastructure does not provide such branches' management, like > > bitbucket/stash do for instance. On the other hand, and more important, a > > project is not hierarchical organization, but a a meritocratic one. > > > > I recommend you this blog post in case you want to read a bit more: > > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/ > > > > If someone has permissions to do (i.e., he is a committer), he can do it, > > simple The tool provide you instruments to revert those changes in case > on > > involuntary errors. > > > >> It would be ideal to have someone who > >> is NOT performing the majority of changes on the "develop" branch take > >> this > >> role to coordinate releases, ensure minimal coding standards, run > through > >> unit and integration tests, before signing off on the release and > issuing > >> the release artifacts. > > You seem to be imagining an individual with a job which is shared in > by the community. In healthy communities, a release happens when > there's a consensus to have a release. There is no person who 'ensures > minimal coding standards', that's everyone watching commits. There's > no one 'running unit and integration tests' because (a) every > committer does this before every commit, (b) Jenkins does it, (c) the > release process does it. (d) there's no signing off on a release. The > RM puts it up for a vote, and PMC members vote. > > > > > > > > Release comes after that. The release manager is responsible on creating > a > > proper release, which must include a code release and should include > > binaries too. Each artifact release must be signed. Demonstrate your > ability > > as a project to produce releases is one of the goals of the incubation. > But > > we are not yet there, step by step. > > > > Hope that helps. > > > > Cheers, > > > > > > -- > > Sergio Fernández > > Partner Technology Manager > > Redlink GmbH > > m: +43 660 2747 925 > > e: [email protected] > > w: http://redlink.co >
