Re: [DISCUSS] Do we want to keep “seconding” for core?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Do we want to keep “seconding” for core?

Robert Scholte-8
To me the most important reason for seconding is to have at least some  
kind of consensus per issue before merging to master.
I don't want to get in the same situation again and if that means  
seconding, then I'm fine with that even if it slows down the process.  
Quality is much more important.

thanks,
Robert

On Sat, 10 Feb 2018 19:09:33 +0100, Stephen Connolly  
<[hidden email]> wrote:

> When we had the “big reset” I asked for seconding before merging as the
> priority was to get a functioning release out.
>
> IMHO outside of burndown towards a release, a successful CI build of the
> branch, providing the branch is fast-forward mergable (not that we  
> actually
> do a fast forward merge - merge policy being a separate topic, just that
> all commits are on top of master without rebasing) should be all that is
> required to merge (the release manager, ie whoever steps up to do a
> release, may revert any problematic merges when time comes to actually
> release)
>
> Once a release manager has stepped up and declared the start of a
> burn-down... in that case seconding should apply.
>
> Wdyt?
>
> (Ps I haven’t declared burn down for core *yet*, but I will in the next
> week or two)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Do we want to keep “seconding” for core?

Hervé BOUTEMY
sure, the good reasons behind this process have to be understood

Core really requires deeper review than any other component, because the
impact is heavier and because reviewing is more complex then require more
formal way to ask for others to take time to review.
The other component IMHO that would require same review is Maven Artifact
Resolver, for the same cause: heavier impact and harder review

Regards,

Hervé

Le dimanche 11 février 2018, 20:28:11 CET Stephen Connolly a écrit :

> On Sun 11 Feb 2018 at 19:18, Robert Scholte <[hidden email]> wrote:
> > To me the most important reason for seconding is to have at least some
> > kind of consensus per issue before merging to master.
> > I don't want to get in the same situation again and if that means
> > seconding, then I'm fine with that even if it slows down the process.
> > Quality is much more important.
>
> I am fine with that, I just am happier if everyone understands they why and
> how.
>
> I don’t want people thinking “stephen shoved this in and it’s here to stay
> because Stephen”
>
> From my PoV it was a necessary evil for the big reset. We are well post
> reset now, if the majority still see value in the practice over and above
> the cost of that practice... let’s keep doing it ;-)
>
> > thanks,
> > Robert
> >
> > On Sat, 10 Feb 2018 19:09:33 +0100, Stephen Connolly
> >
> > <[hidden email]> wrote:
> > > When we had the “big reset” I asked for seconding before merging as the
> > > priority was to get a functioning release out.
> > >
> > > IMHO outside of burndown towards a release, a successful CI build of the
> > > branch, providing the branch is fast-forward mergable (not that we
> > > actually
> > > do a fast forward merge - merge policy being a separate topic, just that
> > > all commits are on top of master without rebasing) should be all that is
> > > required to merge (the release manager, ie whoever steps up to do a
> > > release, may revert any problematic merges when time comes to actually
> > > release)
> > >
> > > Once a release manager has stepped up and declared the start of a
> > > burn-down... in that case seconding should apply.
> > >
> > > Wdyt?
> > >
> > > (Ps I haven’t declared burn down for core *yet*, but I will in the next
> > > week or two)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
>
> Sent from my phone



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]