On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <br...@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 < > dsetrak...@apache.org> > > wrote: > > > >> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <c...@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" <br...@apache.org> > >> wrote: > >>>> On 27.07.2015 07:47, Dmitriy Setrakyan wrote: > >>>>> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <br...@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 > > > > > >
