Sweet :) On Wednesday, April 6, 2016, Lewis John Mcgibbney <[email protected]> wrote:
> Yep Henry np > > https://cwiki.apache.org/confluence/display/JOSHUA/Joshua+Meetups#JoshuaMeetups-Logistics > We will put GHangout details in there closer to the time. > > On Wed, Apr 6, 2016 at 8:23 AM, Henry Saputra <[email protected] > <javascript:;>> > wrote: > > > 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 < > > [email protected] <javascript:;>> wrote: > > > > > 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] <javascript:;>> > 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:;> > > > > <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:;> > > > > <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:;> > > > > <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:;> <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:;> <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:;> > > > > <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* > > > > > > > > > -- > *Lewis* >
