[Biopython-dev] Moratorium on commits?

[Peter Cock]

On Sun, Aug 11, 2013 at 7:28 PM, Morten Kjeldgaard <mok at bioxray.dk> wrote:
>
> On 09/08/2013, at 21:06, Peter Cock <p.j.a.cock at googlemail.com> wrote:
>
>> On Fri, Aug 9, 2013 at 6:26 PM, João Rodrigues <anaryin at gmail.com> wrote:
>>> Dear all,
>>>
>>> The situation with the occupancy in the PDBParser led to think of one
>>> thing.
>>>
>>> Since not everybody is in the same timezone, has the same availability,
>>> etc, what about we introduce a brief moratorium over commits of say 3
>>> days (except for critical bug fixes)? This will give everybody probably
>>> enough time to read the email and give their opinion.
>>>
>>> The downside is that it will make things roll a bit slower but then
>>> again, 3 days is not so much..
>>>
>>> Cheers,
>>>
>>> João
>>
>> I don't think that's really needed for small commits like
>> this which are simple to interpret. In this case there were
>> three opinions in favour of the idea, with a fourth counter
>> view appearing later, resulting in a further tweak.
>>
>> Longer periods of discussion are far more important on
>> large code additions or major changes.
>
> Sorry, but I don't agree that this is a "small commit". It may
> not be large in terms of number of bytes, but it is large in
> terms of impact, since it affects users' programs in
> unpredictable ways.

Hello again Morten,

I did mean small in number of code change, which I
tried to make clear from the rest of the email, but
as discussed below, I also think the PDB occupancy
change was also small in terms of behaviour.

> Whenever a change is made that affects values
> returned to the user, it is worth spending a few days
> discussing it,  to let people have a chance to think
> through the consequences of the change.

Almost any change impacts the user in some way.

I still feel this was a minor change (although of
course important to some, including you). This is
parsing of malformed PDF files where the user
ALREADY gets a warning (or error in strict mode,
where there would be no functional change) that
there is a problem with the occupancy data.

One reason why I specifically talked about small
commits (in the sense of a simple diff) above is
they are trivial to revert if the need arises, or as
in this case, modify:
https://github.com/biopython/biopython/commit/500c3c2ea900fd8c8f5123f571d4d9a244ee898e

This change was suggested and supported by
people who've been actively contributing to the
Biopython structural module for some time, so I
had reason to trust their good judgement, and as
I wrote at the time there was a clear consensus
with three people in all happy with the idea:
http://lists.open-bio.org/pipermail/biopython-dev/2013-August/010773.html

Changes where there isn't clear agreement are
generally discussed over a longer time period.

Note that Biopython is already relatively strict
about not breaking things and preserving backwards
compatibility (to the point where it does delay new
features). We do care about not breaking existing
scripts without warning - so when people speak up
on the list that something is likely to cause them
trouble, we do listen.

Is that any clearer?

Regards,

Peter