Sounds like the release process documentation would be a good thing to be addressed at ApacheCon.
On Tuesday, April 5, 2016, Matt Post <[email protected]> wrote: > Hi Tom, > > Thanks for this. I adopted a simplified version of git-flow a while back: > > - Trying to use branches for experimental stuff > > - Merging back into "master" when done (with --no-ff), with the rule that > pushes to master should always pass all the test suites > > - Using a release branch for actual point releases. > > I'd be happy to continue this and even to do it right; it's probably a > good idea especially if development picks up the way it seems to be. > > Once I get to a redo of the documentation (which will probably not happen > prior to ApacheCon), I can formalize this (though I'm happy if someone else > wants to prior to that. > > matt > > > > On Mar 29, 2016, at 3:40 PM, Tom Barber <[email protected] > <javascript:;>> wrote: > > > > Moved over to dev@ with useful information still in place. > > > > Yeah I don't think the ASF is onboard yet with git pull type workflows. > Its > > still mostly peer review through the reviewboard and pull request > reviews. > > I'm not saying we do away with them either, but I do think the ASF > doesn't > > make the best use of git with the forking strategy for established > > committers. > > > > Clearly if you don't have commit rights to the project it would need to > be > > a PR/reviewboard submission anyway, but from an entirely personal > > perspective I much prefer people developing on the same repository > instead > > of github forks as it makes for much easier collaboration and keeping the > > code in sync. Of course you can accept pull requests onto feature > branches > > etc as well. > > > > As I said, it doesn't have to be set in stone either, as committers we > just > > make sure we don't commit to the master (or other named branch) that is > for > > releases. > > > > Even on personal forks I tend to do git flow and just push back to the > > correct branch for the project. > > > > Anyway as I said just my 2 cents. > > > > On 29 March 2016 at 20:26, Henry Saputra <[email protected] > <javascript:;>> wrote: > > > >> We could bring this discussion back to dev@ list. > >> > >> I like the git flow model too, but I don't think any other ASF projects > >> using develop branch concept. For now all PRs and patches are targeted > for > >> master. > >> > >> - Henry > >> > >> On Tue, Mar 29, 2016 at 12:06 PM, Tom Barber <[email protected] > <javascript:;>> > >> wrote: > >> > >>> To keep code stable I'm a fan of "git flow" either using the tooling or > >>> just using the methodology, that way you always have a stable branch to > >>> work off. > >>> > >>> Master branch never gets commits to it and always reflects the latest > >>> release > >>> Development branch gets sporadic commits to fix stuff or add minor new > >>> bits > >>> Feature-XYZ is a major new feature branch branched from development. > >>> Development gets merged into it to keep it in sync and when a feature > is > >>> complete and tests passing, it gets merged into development > >>> Hotfix-XYZ is branched from Master to provide hotfix patches and gets > >>> merged back into master and development. > >>> Release-XYZ is a release branch, minor bug fixes go into this branch > >>> prior to release, then gets merged back into master & development when > its > >>> done. > >>> > >>> This way you keep your codebase clean and works well when you have a > >>> bunch of different development drives going on. > >>> > >>> For more information: > >>> http://nvie.com/posts/a-successful-git-branching-model/ > >>> > >>> Matt, over on OODT we generally do a code review process before merging > >>> PR's back into the mainline anyway, but I think the above can add some > more > >>> protection whilst allowing people to develop reasonably freely without > a > >>> miriad of forked branches or local offline clones. > >>> > >>> Cheers, > >>> > >>> Tom > >>> > >>> -------------- > >>> > >>> Director Meteorite.bi - Saiku Analytics Founder > >>> Tel: +44(0)5603641316 > >>> > >>> (Thanks to the Saiku community we reached our Kickstart > >>> < > http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/ > > > >>> goal, but you can always help by sponsoring the project > >>> <http://www.meteorite.bi/products/saiku/sponsorship>) > >>> > >>> On 29 March 2016 at 19:53, Lewis John Mcgibbney < > >>> [email protected] <javascript:;>> wrote: > >>> > >>>> > >>>> > https://builds.apache.org/view/H-L/view/Joshua/job/Joshua%20master%20build/ > >>>> > >>>> On Tue, Mar 29, 2016 at 11:23 AM, Lewis John Mcgibbney < > >>>> [email protected] <javascript:;>> wrote: > >>>> > >>>>> I'm creating a Jenkins build which will poll master branch every > minute > >>>>> and execute a build if a change has been made > >>>>> It will be available and configurable from here > >>>>> https://builds.apache.org/view/H-L/view/Joshua/ > >>>>> Ta > >>>>> > >>>>> On Tue, Mar 29, 2016 at 11:14 AM, Matt Post <[email protected] > <javascript:;>> wrote: > >>>>> > >>>>>> Okay, before voting myself, I'd like some discussion. > >>>>>> > >>>>>> I'm generally supportive of adding contributors . This does > represent > >>>>>> a shift away from the way things have been working, though — where > there > >>>>>> may be multiple contributors, but in effect, all commits have come > from me > >>>>>> or through pull requests. > >>>>>> > >>>>>> So I'd really like to have some formal processes in place that > ensure > >>>>>> that people don't start breaking things with their pushes. The way > we've > >>>>>> handled it so far is to have self-contained, fast (well under a > minute) set > >>>>>> of tests under $JOSHUA/test, in the form of shell scripts that run, > do > >>>>>> whatever they want, and exit 0 upon success. It'd be nice to have > these be > >>>>>> required, and to work as some mechanism where if you don't write a > test > >>>>>> case, then you can't complain if your stuff gets broken. I'd also > love if > >>>>>> these regressions could be run every night or even upon committing. > >>>>>> Finally, I'd like to have a list of expectations for pushers. > >>>>>> > >>>>>> Does this sound okay to folks? If anyone knows of Apache tools or > >>>>>> conventions that could support (or extend) these proposals, I'd be > >>>>>> interested to hear them. Moving Joshua development from an > essentially > >>>>>> single-user project to a larger group of committers will be a > learning > >>>>>> experience for me. > >>>>>> > >>>>>> matt > >>>>>> > >>>>>> > >>>>>> > > -- *Lewis*
