ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: Jira Process
Date Mon, 27 Jul 2015 07:30:51 GMT
On 27.07.2015 09:17, Atri Sharma wrote:
> On Mon, Jul 27, 2015 at 12:42 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>
>> 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?
>>
>>
> As someone who has seen problems with bad commits, I totally second
> Dmitriy. Developer bugs be better caught and prevented rather than
> backpatched and fixed.

We've all seen problems with bad commits. Bugs happen. If it's
accidental, live with it. If it's consistent from some person, teach
said person to do better. There's no reason to go all paranoid over a
potential occasional bug in a commit.

I mean, it's ridiculous to go all agile with sprints and scrums and CI
and whatnot, and then block progress because you're afraid to trust your
fellow developers to not goof off all the time.

-- Brane


Mime
View raw message