+1 from me too.
—
AY
On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote:
> We have done all this for previous releases and we know it has not worked
> well. So how giving it one more try is going to help here. Can someone
> outline what will change for 4.0 which will make
Well put Mick
+1
On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko
wrote:
> +1 from me too.
>
> —
> AY
>
> On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote:
>
>
> > We have done all this for previous releases and we know it has not
> worked
> > well. So how giving it one mo
I guess I look at the initial voting in of committers as the process
by which people are trusted to merge things in. This proposed process
revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily
picked) wants to merge a new feature into trunk during the freeze, now
they're not allowed?
Ultimately, we have a consensus driven development. If Jonathan or Dave
strongly disagrees with this, they can share their strong disagreement.
Jonathan shared his concern about dissuading contributors.
What's absurd is trying the same thing we've tried for 10 years and
expecting things to magica
That’s a peculiar way of looking at it.
Committer status is not an absolute right to autonomy over the codebase. It’s
an embodiment of trust that you will follow the community's prevailing rules
around commit, and that you’re competent to do so.
If the community wants to change those rules
I guess I look at the idea of changing the branching strategy as a
means of blocking work as a very odd way of solving a human problem.
Having a majority of votes temporarily block potentially good work
might be a good thing, and it might not matter at all. It might also
frustrate some folks who h
It’s not like this is an irrevocable change.
If we encounter a scenario that seems to question its validity, or its general
applicability, it can be raised on the mailing list and we can revisit the
decision, surely? I can think of at least one way to weaken the rules in such
a scenario, wit
+1 here as well
On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko
wrote:
> +1 from me too.
>
> —
> AY
>
> On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote:
>
>
> > We have done all this for previous releases and we know it has not
> worked
> > well. So how giving it one more
You're right - if we do decide we're wrong we can always create the
branch later.
I retract my -1.
On Tue, Jul 10, 2018 at 10:50 AM Benedict Elliott Smith
wrote:
>
> It’s not like this is an irrevocable change.
>
> If we encounter a scenario that seems to question its validity, or its
> general
> On Jul 10, 2018, at 10:18 AM, Jonathan Haddad wrote:
>
> I guess I look at the initial voting in of committers as the process
> by which people are trusted to merge things in. This proposed process
> revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily
> picked) wants to merge
+1 here too
On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson wrote:
> +1 here as well
>
> On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko
> wrote:
>
> > +1 from me too.
> >
> > —
> > AY
> >
> > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote:
> >
> >
> > > We have done all
If this motivates individuals and organizations to contribute time and
resources to testing more before the release then +1. The varied testing
before the release will make a huge difference.
> On Jul 10, 2018, at 12:30 PM, Jeff Jirsa wrote:
>
> Ultimately, we have a consensus driven developm
+1 from me as well. Let's try it out
On 7/10/18, 11:23 AM, "Sam Tunnicliffe" wrote:
+1 here too
On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson wrote:
> +1 here as well
>
> On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko
> wrote:
>
> > +1 from me too
13 matches
Mail list logo
