Self committing... allowed or not?

Michelle Sullivan michelle at
Sun Jul 19 20:30:49 UTC 2015

Baptiste Daroussin wrote:
> On Sun, Jul 19, 2015 at 06:44:26PM +0200, Michelle Sullivan wrote:
>> Baptiste Daroussin wrote:
>>> On Sun, Jul 19, 2015 at 05:19:08PM +0200, Michelle Sullivan wrote:
>>>> Dimitry Andric wrote:
>>>>> On 19 Jul 2015, at 14:02, Michelle Sullivan <michelle at> wrote:
>>>>>> please correct me if I'm wrong but isn't self committing (those with the
>>>>>> commit bit committing their own patches without QA/review/adding
>>>>>> patchfiles to the PR) against the rules?... or is it just a free-for-all
>>>>>> now?
>>>>> If they are the maintainer, it is OK by definition.  Otherwise, approval
>>>>> from either the maintainer or portmgr@ is needed.
>>>>> However, a number of people are on vacation, and they have notified
>>>>> other developers that is OK to fix their ports while they are away.
>>>>> Within reason, of course. :-)
>>>>> In any case, which specific ports are you worried about?
>>>>> -Dimitry
>>>> Here's the case and the three referenced commits:
>>>> And I know the top-level dependency will now break other things because
>>>> of a minor detail that the committer did not take into account... That
>>>> said I don't know if any other dependencies on it exist (so therefore it
>>>> might not break anything else - however I am fairly sure it wasn't
>>>> checked by the committer because of the speed and absoluteness of the
>>>> change) because I don't need it/use it myself... but that is not the
>>>> point.  I was 'just lucky' to come across this change process as I was
>>>> not looking for anything, just happened to be in the right place at the
>>>> right time to see it, and considering the hoops use plebs (those without
>>>> the commit bit) have to jump through I thought it was rather ironic that
>>>> 3 separate ports were changed, no testing was recorded in the PR as we
>>>> the plebs are required to do, no patches uploaded as we the plebs have
>>>> to do and no review as we the plebs have to have... 
>>> do you appear to know the said ports were broken (segfault) at startup because
>>> of various libssl mixup, they have been tested and fixed. if another issue
>>> appears on those ports I will fix them.
>> I'm guessing you missed the '--use-ldap' in the top level dependency... 
>> I'm assuming you know there are issues with openldap and the use base vs
>> use ports issue... particularly with dependent ports and incompatible
>> options... your 'fix' quite possibly fixed one problem and caused
>> another (not your fault as it happens - but an unintended consequence of
>> an unchecked change... if you want to bring order and stability this is
>> not the way to proceed.  (That said neither is laborious change control
>> and peer review, but some is needed and the rules should apply to
>> everyone or there will be more chaos.))
> I haven't missed the --use-ldap dependency, openldap does respect USE_OPENSSL as
> well so even if the situation is quite "broken" dealing with openssl, my commit
> reduces the inpact on seafile.

Which is why I said 'not your fault' and in the long run the changes
will probably reduce any issues (rather than cause some), however in the
short term they may have broken other things that were working... which
was the point of my mail and referring to the rules we have to work by.

> In fact what I am working on is enforcing openssl (or libressl at user choice)
> from ports directly (which is why I worked on the ports in the first place -
> after someone complained on IRC that one month after the ticket being created
> nothing happened).

So you're calling this maintainer timeout?

Personally I would have expected patches to be proposed to the
maintainer for review and then timeout after an arbitrary time ... 
works differently if you run the ports tree I guess...  For us plebs I
had proposed a new port, and had to wait for another maintainer because
that maintainer "does all that family" and he was busy so instead of the
new port being approved and all done and dusted within a couple of days
it was over a month in the end... (and if anyone recognises themselves,
no disrespect to either the committer or that person, just a
comment/example on how it works for the rest of us.)

My problem here and the reason for the email in the first place as there
are rules to follow - or so we are lead to believe, some people seem to
skip them whilst others are made to follow them no matter what.  The
rules should be set out and followed by anyone and everyone... There
isn't a single build that goes by on my measly 1000(ish) ports where
something breaks which is why I build both my tree ( my tree that is
still using and still working well with pkg_* tools ) and the 'ng' tree
(fetched via portsnap)...  I should see my ports tree failing because of
course the pkg_* tools don't work any more and "can't work" with the
ports tree, but instead I see the reverse, I get the current ports tree
failing...  People changing the names of options (port options),
new/updated ports with incompatible options enabled (not by default but
by legacy and then other things getting changed)... this type of change
had I been using the dependency in this issue would likely have caused
more build failures... it may cause failures with other people... it may
fix things for others where it was failing... the problem is the patch
was put in very quickly for not one, but 3 ports, without the
maintainers being given an opportunity to review (and in this case I
think it's the same maintainer, but that is  not the point.)

What would you have done if it was one of my ports that was a higher
place in the dependency tree?  Just made the change and possibly broken
other stuff? 

Seriously, every change to the build system has to be verified and
approved by portmgr@ surely a port (especially one which appears in
dependency trees of other ports) should have some sort of change control
where the maintainer  reviews and approves proposed changes? (or it goes
for timeout if the maintainer doesn't reply to the proposed patch -
which happened with one of 'my' ports when I was on holiday and someone
applies the patches with a comment such as 'I thought I might not get a
response on this port')

When it comes to change control you're either being professional, or
you're not, your choice, everyone else's perception.

Michelle Sullivan

More information about the freebsd-ports mailing list