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]> 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]> 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]> >> 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]> 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]> 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]> 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 >>>>>> >>>>>> >>>>>>
