Dan, 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
