You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@joshua.apache.org by Matt Post <po...@cs.jhu.edu> on 2016/04/05 23:13:01 UTC
Re: Joshua development strategy
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 <to...@analytical-labs.com> 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 <he...@gmail.com> 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 <to...@analytical-labs.com>
>> 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.mcgibbney@gmail.com> 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.mcgibbney@gmail.com> 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 <po...@cs.jhu.edu> 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
>>>>>>
>>>>>>
>>>>>>
Re: Joshua development strategy
Posted by Henry Saputra <he...@gmail.com>.
Sweet :)
On Wednesday, April 6, 2016, Lewis John Mcgibbney <le...@gmail.com>
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 <henry.saputra@gmail.com
> <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 <
> > lewis.mcgibbney@gmail.com <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 <post@cs.jhu.edu <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 <tom@analytical-labs.com
> <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 <henry.saputra@gmail.com
> <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 <
> > tom@analytical-labs.com <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 <
> > > > >>> lewis.mcgibbney@gmail.com <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 <
> > > > >>>> lewis.mcgibbney@gmail.com <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 <post@cs.jhu.edu
> <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*
>
Re: Joshua development strategy
Posted by Lewis John Mcgibbney <le...@gmail.com>.
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 <he...@gmail.com>
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 <
> lewis.mcgibbney@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 <po...@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 <tom@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.saputra@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 <
> tom@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.mcgibbney@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.mcgibbney@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 <post@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*
> >
>
--
*Lewis*
Re: Joshua development strategy
Posted by Henry Saputra <he...@gmail.com>.
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.mcgibbney@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 <po...@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 <tom@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.saputra@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 <tom@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.mcgibbney@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.mcgibbney@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 <post@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*
>
Re: Joshua development strategy
Posted by Lewis John Mcgibbney <le...@gmail.com>.
Sounds like the release process documentation would be a good thing to be
addressed at ApacheCon.
On Tuesday, April 5, 2016, Matt Post <po...@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 <tom@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.saputra@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 <tom@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.mcgibbney@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.mcgibbney@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 <post@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*