Nothing terminally broken. There were a couple of incorrect merges to master, but it's a simple matter of getting used to the process I think.
On Sun, Sep 13, 2015 at 4:36 PM, Konstantin Boudnik <c...@apache.org> wrote: > I've just realized that I haven't read this one on time. It's been over a > month now and looks like nothing has been terminally broken just yet, > right? > > > Cos > > On Mon, Aug 03, 2015 at 02:43AM, Dmitriy Setrakyan wrote: > > From what I am seeing, majority of community members are OK with CTR > with a > > suggestion that we raise the bar for becoming a committer into Ignite > (this > > will require a separate thread). > > > > If there are no strong objections, let's give CTR a shot. We can always > > come back to this discussion if needed. > > > > I have added "Commit-Then-Review" section to Jira process: > > https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process > > > > Feel free to comment. > > > > D. > > > > On Tue, Jul 28, 2015 at 11:17 AM, Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > +1 for RTC. For now rules to become a committer are pretty "soft", CI > and > > > JIRA processes are still changing, etc. I believe without additional > > > control quality of our product will deteriorate in such environment. > > > > > > Let's graduate first, establish development processes, define > requirements > > > to become a committer and only then start thinking about switching to > CTR > > > which is for sure more suitable for well-established TLP. > > > > > > On Tue, Jul 28, 2015 at 9:11 PM, Konstantin Boudnik <c...@apache.org> > > > wrote: > > > > > > > On Tue, Jul 28, 2015 at 06:23AM, Vasilisa Sidorova wrote: > > > > > In a perfect world I agree with Brane. > > > > > > > > > > But there is top class from each igniter to trust each others on > the > > > > 1000% > > > > > and always to be ready that something go sideways. This process > take > > > > time. > > > > > > > > Actually, no one is talking about 100% trust. That's why post-commit > > > > reviews > > > > are welcome, and reverts aren't removed from the table as a faculty > of > > > last > > > > resort. > > > > > > > > We are talking about trusting a committer not to do silly things that > > > break > > > > the master. People will be making mistakes anyway; reviewers are > people > > > too > > > > and will be making mistakes as well. There's no way to stop it: but > > > > there're > > > > ways to mitigate the harm and to make sure bad commits are few and > far > > > > apart. > > > > > > > > Cos > > > > > > > > > So I think that our Jira process should be flexible because Ignite > is > > > > young > > > > > project. > > > > > > > > > > As a first step we can get together to commit simple fixes without > > > review > > > > > and take as a "simple" issues in Jira with "trivial" priority. > > > > > > > > > > When our community credit of trust will grows up we can review Jira > > > > process > > > > > and decide to take as a "simple" issues in Jira with "minor" > priority > > > or > > > > > find some new solution. > > > > > > > > > > Etc... > > > > > > > > > > Regards, > > > > > Vasilisa > > > > > > > > > > > > > > > > > > > > -- > > > > > View this message in context: > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1917.html > > > > > Sent from the Apache Ignite Developers mailing list archive at > > > > Nabble.com. > > > > > > > >
