Yeah I was wondering about that too. I suspect it is to make the
visual code review of the PR easier to digest.
We can document it on the Github/PR language but we also need to
produce a nice contribution guide that helps folks whether they're
coming from Github, are in the PPMC, and so on.
Thanks
Joe
On Wed, May 6, 2015 at 10:39 AM, Dan Bress <[email protected]>
wrote:
+1 on all this stuff.
As a side note, I noticed on a PR Busbey suggesting that people squash
their commits before submitting a PR. I know I haven't been doing this,
and wouldn't mind hearing some pros/cons to doing this. Whatever we
decide, can we include some language in the git hub / pull request
section
that describes the suggested approach.
Dan Bress
Software Engineer
ONYX Consulting Services
________________________________________
From: Mark Payne <[email protected]>
Sent: Wednesday, May 6, 2015 10:22 AM
To: [email protected]
Subject: Re: Consistency with Git
I vote +1 for these suggestions. I typically name feature branches
after
the feature, rather than the ticket. But I can see the advantage to
having
the ticket name in there as well. I like the suggestion to include both.
For release branches, I think this will help a lot. I’ve created and
destroyed several release branches trying to get this release done.
Having
the common parent would ensure isolation from develop but still allow
me to
easily destroy the branch rather than doing a release:rollback and
hoping
that all works well.
Thanks
-Mark
From: Joe Witt
Sent: Wednesday, May 6, 2015 9:57 AM
To: [email protected]
Team,
It's been a few months and we started out with some ideas on how to do
things and each of us interpreted that slightly differently. That
will continue to be true but we should document these things and keep
getting better and more consistent. One area to consider then is the
usage of Git and our adherence to the Gitflow [1] workflow as we had
discussed.
In my opinion there is little call for us to deal with maintenance
branches. So here i am just talking about 'feature branches' and
'release branches'. What I'd propose is that we use what we've
learned and provide some better guidance on how to name the branches
and the life-cycle of them.
For 'feature branches':
- Recommend naming them 'NIFI-XYZ[-description]' The [-description]
would be optional. But for example this means the 'ListHDFS' branch
we have would have been NIFI-553-ListHDFS.
- This naming scheme helps people to know precisely which branch that
is about and it also promotes cohesive feature branches (that are
about a particular JIRA).
- Once the feature is complete and has been reviewed it can then be
merged into develop
- It isn't clear to me when it is the right time to clean up these
branches. In my mind it seems like once the feature branch has been
merged to develop and part of a release then the feature branch can be
removed. It isn't necessary for Git itself to do this but seems like
good housekeeping.
For 'release branches'
- Recommend naming them 'release-nifi-X.Y.Z'.
- This release branch would live on forever. When generating an RC it
should branch from that release branch. This way as RC's may come and
go we're not polluting the commit history.
- Once a given RC is accepted it can be merged back to the release
branch, master, and develop
- This extra sub-branch for the RC sounds a bit like overkill. But it
exists to ensure that we do not pollute the commit history of the
release and beyond but also to ensure the community can keep
progressing with the develop branch.
- If for any reason we had to do an emergency type patch to a release
or whatnot we could do so with this branch and/or we can use the tag
which gets generated during the release process.
There needs to be more discussion around the entire lifecycle of
contribution of code that considers all roles of the community
including those submitting PRs from Github. But this initial note is
just to get some consistency and open up for discussion.
[1]
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Thanks
Joe
