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 <miche...@sorbs.net> 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: >>>> >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199265 >>>> >>>> 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 http://www.mhix.org/ _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
