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

Reply via email to