> On 2 May 2015, at 22:54, Neil Stevenson wrote:
>
> Hi,
> Is there a list of enhancements being worked on ?
>
> I have an improvement to GFSH I'm looking at. Although it's unlikely, someone
> else may be working on the same
I'm going to look at upgrading the Spring & JLine dependencies when
the
I am a huge fan, practitioner, and advocate for [1] - hence unconditional +1
Thanks,
Cos
On Fri, May 01, 2015 at 06:53AM, Anthony Baker wrote:
> I suggest we adopt the gitflow model for branching as described in [1] and
> [2]. Following an established and consistent pattern for branching make
Same here. And in my experience having mentors, if they are indeed active
mentors, is generally a positive thing as it adds the experience and direct
contribution to the new project.
Cos
On Fri, May 01, 2015 at 03:55PM, jan i wrote:
> Hi
>
> I would like to ask the community, how is Mentors vie
On Fri, May 1, 2015 at 8:55 AM, jan i wrote:
> Hi
>
> I would like to ask the community, how is Mentors viewed in this project ?
>
> - Are we (just) external advisers, that basically check/inform the apache
> project about the apache way.
>
> or
> - Are we part of the project, and expected to part
Hi Neil!
On Sat, May 2, 2015 at 2:14 AM, Neil Stevenson
wrote:
> Hi,
> Is there a list of enhancements being worked on ?
>
> I have an improvement to GFSH I'm looking at. Although it's unlikely,
> someone else may be working on the same
We're still migrating onto the ASF infrastructure (expect
Hi,
Is there a list of enhancements being worked on ?
I have an improvement to GFSH I'm looking at. Although it's unlikely,
someone else may be working on the same
Neil
On Fri, May 1, 2015 at 11:44 AM, Dan Smith wrote:
> On Fri, May 1, 2015 at 6:53 AM, Anthony Baker wrote:
>
>> I suggest we adopt the gitflow model for branching as described in [1] and
>> [2]. Following an established and consistent pattern for branching makes
>> it easier for new users and devs
On Fri, May 1, 2015 at 7:07 AM, jan i wrote:
> Public feature branches should only be used, when multiple people work on a
> feature. A feature branch is started after the intention is made clear on
> dev@
>
One thing we've done within our organization is make a distinction between
public featur
Thanks for commenting jan. To me the value of the release branch is allowing
uninterrupted ongoing work on the develop branch while isolating the work to
stabilize the code in preparation for a release. I would hesitate to merge
directly from develop to master until we had proven stability whi
IMHO it will depend on the mentors will to play the roles.
>From a community perspective, any help will definitely be much appreciated
and welcome!
We'll setup people.a.o soon as well...
On Fri, May 1, 2015 at 6:55 AM, jan i wrote:
> Hi
>
> I would like to ask the community, how is Mentors vie
On Fri, May 1, 2015 at 11:44 AM, Dan Smith wrote:
> On Fri, May 1, 2015 at 6:53 AM, Anthony Baker wrote:
>
>> I suggest we adopt the gitflow model for branching as described in [1] and
>> [2]. Following an established and consistent pattern for branching makes
>> it easier for new users and devs
On Fri, May 1, 2015 at 8:55 AM, jan i wrote:
> Hi
>
> I would like to ask the community, how is Mentors viewed in this project ?
>
> - Are we (just) external advisers, that basically check/inform the apache
> project about the apache way.
>
> or
> - Are we part of the project, and expected to part
On Fri, May 1, 2015 at 8:55 AM, jan i wrote:
> Hi
>
> I would like to ask the community, how is Mentors viewed in this project ?
>
> - Are we (just) external advisers, that basically check/inform the apache
> project about the apache way.
>
> or
> - Are we part of the project, and expected to part
Since using this git flow for a while now I would strongly back the take up of
this branch process.
Lyndon Adams
London, SW11
> On 1 May 2015, at 17:44, Dan Smith wrote:
>
>> On Fri, May 1, 2015 at 6:53 AM, Anthony Baker wrote:
>>
>> I suggest we adopt the gitflow model for branching as desc
14 matches
Mail list logo
