Hi,
I agree our review is done after the commit... and this is great. I don't
think we want to push a boring review process in this project. I have
enough of this in my day time job. :) I guess the goal was to have a
release without disturbing the regular development. At least not too much.
Now I see how tags can help quick bug fixes; but if I got it right, we will
have code freeze for regular releases.
It looks like new branches are bad because we cannot (or are not supposed
to) delete them. I'm confused about the quick fix. If we don't like new
branches, how would be quick fix without bringing all the on-going features
along with the fix itself?
Please check if I got it right...
Quick bug fix in 2.x.x ("origin/master"):
* Create a branch from the faulty tag.
* Fix the issues in this new branch.
* Call a vote in this new branch.
* The vote passes. You create a tag in this branch.
* You delete the branch.
Normal 2.x.x release ("origin/master"):
* You send a message to the dev list: "Code-freeze. Preparing code for new
release. Only commits related to the release please."
* You make the "origin/master" stable
* You call a vote on "origin/master"
* The vote passes. You create a tag.
* You send a message to the dev list: "Release done. You are free to mess
up the master branch again. ;)"
[]s,
Thiago.
On Thu, Jan 29, 2015 at 2:48 AM, Mark Struberg <[email protected]> wrote:
> Alan, the gitflow way is basically review then commit. Because the
> 'Release Manager' (of whom we lack...) needs to review and choose
> (cherry-pick) EACH AND EVERY SINGLE COMMIT. And even worse - by deleting
> the 'temp' branch afterwards we also loose all the other work later.
>
> And once again:
>
> We must not delete anything from our repos!
>
> We must not squash commits!
>
> We must not loose any history!
> We must guarantee a verifyable code provenance!
>
> Those are no 'should' those are MUST!
>
>
> LieGrue,
> strub
>
>
>
>
>
> > On Thursday, 29 January 2015, 7:51, Alan D. Cabrera <
> [email protected]> wrote:
> > >
> >> On Jan 28, 2015, at 1:59 AM, Romain Manni-Bucau
> > <[email protected]> wrote:
> >>
> >> well it is by design opposed to apache way since if it is used it is
> >> to have the ability to change commit history - if not it is really
> >> useless.
> >
> > I’m sure that I’m being dense but how is this form of branch management
> not the
> > apache way?
> >
> >
> > Regards,
> > Alan
> >
>
