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