Just realized we now have separate Apache Big Data and Apache Con so wont be able to come to the Apache Con one =(
Any chance to have like Google hangout to participate remotely? ;) - Henry On Tue, Apr 5, 2016 at 4:15 PM, Lewis John Mcgibbney < lewis.mcgibb...@gmail.com> wrote: > Sounds like the release process documentation would be a good thing to be > addressed at ApacheCon. > > On Tuesday, April 5, 2016, Matt Post <p...@cs.jhu.edu> 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 <t...@analytical-labs.com > > <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 <henry.sapu...@gmail.com > > <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 <t...@analytical-labs.com > > <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 < > > >>> lewis.mcgibb...@gmail.com <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 < > > >>>> lewis.mcgibb...@gmail.com <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 <p...@cs.jhu.edu > > <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* >
