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