ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Jira Process
Date Mon, 27 Jul 2015 07:12:08 GMT
On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <brane@apache.org> wrote:

> On 27.07.2015 08:49, Atri Sharma wrote:
> > I totally agree on this one.
> >
> > In PostgreSQL, every committer's major changes are normally reviewed by
> > somebody else before the committer pushes the patch. However, for trivial
> > patches, committer normally puts post on developer list stating his
> changes
> > and gives a timeline by which he/she will commit patch and objections
> need
> > to come before that. Giving a day for such patches should be fine, IMO.
>
> Well, over at Subversion, we regularly make major changes on trunk
> without previous review. Our only requirement is that trunk remains
> "stable", i.e., that tests pass; even then, no-one is expected to run
> tests on all supported platforms. Review happens after commit. Sure that
> means occasional bugs creep in, but that would happen regardless.
>
> If we imposed RTC, development of Subversion would literally grind to a
> stop. Developers are volunteers, so they review when they have time,
> which sometimes means a week or more after the actual commit.
>
> Note that for backports to stable release branches, we do have an RTC
> process in place.
>

Can you describe at which point a master becomes a release branch in
Subversion? Also, what happens if an occasional bad commit sneaked into the
release branch?


> Please don't go all control-freak on the source: it should be more than
> enough to have a working CI, perform post-commit reviews and to run
> tests on releases.
>

Not trying to... I was merely describing the dev process as of today.
However, I am not seeing how a post-commit review speeds up the process.
The review still occurs regardless, so why not do a pre-commit review to be
safer?


>
> -- Brane
>
> > On Mon, Jul 27, 2015 at 12:15 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > wrote:
> >
> >> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <cos@apache.org>
> >> wrote:
> >>
> >>> I second.
> >>>
> >>> It's up to the community to go CTR or RTC but former has a way more
> >>> flexibility and way speedier. Esp. considering that Ignite has great
> and
> >>> functional CI in place. We are trying to get CTR running in Bigtop, but
> >>> getting blocked by comprehensive CI being not ready yet.
> >>>
> >> The process in Ignite is that all committers work in separate branches.
> >> Committers are free to commit into their branch as often as required.
> >> However, the process that I prefer is that a review by another committer
> >> must happen before a final merge to the master takes place.
> >>
> >> In my experience, I have seen the simplest of the commits break builds
> or
> >> make wrong assumptions.
> >>
> >>
> >>> Please consider the consequences of the decision you're about to make.
> >>>
> >> I was hoping to arrive to a decision as a result of this discussion.
> >>
> >>
> >>> Cos
> >>>
> >>> On July 26, 2015 11:13:40 PM PDT, "Branko Čibej" <brane@apache.org>
> >> wrote:
> >>>> On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
> >>>>> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <brane@apache.org>
> >>>> wrote:
> >>>>>> On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
> >>>>>>> Igniters,
> >>>>>>>
> >>>>>>> I believe several very valid points have been made on the
general@
> >>>> list
> >>>>>>> about our Jira handling, and how we should improve our Jira
> >>>> process.
> >>>>>>> I have tried to outline the Jira Process we should follow
on our
> >>>> Wiki:
> >>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
> >>>>>>>
> >>>>>>> Please review and provide comments. Let's try to finalize
it within
> >>>> the
> >>>>>>> next couple of days.
> >>>>>> This describes a commit-then-review process. This is absolutely
not
> >>>> what
> >>>>>> you want. There is no need to ask for patch review before
> >>>> committing;
> >>>>>> this should happen after commit. The only case where the ticket
> >>>> review
> >>>>>> stage makes sense is when someone who is not a committer is
writing
> >>>> the
> >>>>>> patch; or when the committer feels she needs extra eyes on the
> >>>> change.
> >>>>> Brane, I am not sure if I understood you correctly. The process
that
> >>>> I
> >>>>> would like to see in Ignite is that absolutely every ticket undergoes
> >>>> a
> >>>>> review process before it gets merged to the main master branch,
> >>>> regardless
> >>>>> of whether it is done by a committer or not.
> >>>>>
> >>>>> Are you suggesting that the review process for committers should
be
> >>>>> optional?
> >>>> Yes of course. The default process for making changes should be:
> >>>> commit,
> >>>> then review (CTR). This means that any committer can make any change
> >>>> without asking for a review first, and other committers review the
> >>>> changes after the commit.
> >>>>
> >>>> What you're proposing is the review, then commit (RTC) process, which
> >>>> a)
> >>>> implies that you don't trust committers even for trivial changes, b)
> >>>> slows down development and c) IMO is contrary to the spirit of open
> >>>> source. A committer should know when a change really needs review
> >>>> before
> >>>> committing, otherwise you shouldn't have made her a committer in the
> >>>> first place.
> >>>>
> >>>> My point in that discussion thread is that you guys are using Jira far
> >>>> too much for trivial stuff. It's a waste of time and resources to go
> >>>> through all the Jira steps for simple changes; instead, you should
> >>>> learn
> >>>> to write descriptive commit log messages and use Jira only for
> tracking
> >>>> large changes or bugs that can't be addressed immediately.
> >>>>
> >>>>
> >>>> As it stands, you're proposing to change an open development process
> >>>> into a bureaucratic nightmare. Please don't.
> >>>>
> >>>> -- Brane
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message