svn commit: r504590 - in head/net: samba46 samba47 samba48

Tue Jul 2 15:35:20 UTC 2019

On 3/07/2019 1:15 am, Torsten Zuehlsdorff wrote:
> 
> 
> On 02.07.19 14:53, Kubilay Kocak wrote:
>> On 2/07/2019 10:28 pm, Tĳl Coosemans wrote:
>>> On Tue, 2 Jul 2019 13:16:47 +0200 Mathieu Arnold <mat at FreeBSD.org> wrote:
>>>> On Tue, Jul 02, 2019 at 12:31:35PM +0200, Torsten Zuehlsdorff wrote:
>>>>> On 02.07.19 12:23, Mathieu Arnold wrote:
>>>>>> On Mon, Jul 01, 2019 at 01:23:34AM +0200, Timur I. Bakeyev wrote:
>>>>>>> On Sat, 29 Jun 2019 at 22:50, Baptiste Daroussin
>>>>>>> <bapt at freebsd.org> wrote:
>>>>>>>> Le 29 juin 2019 20:40:53 GMT+02:00, "Timur I. Bakeyev"
>>>>>>>> <timur at bat.ru> a
>>>>>>>> écrit :
>>>>>>>>> Tonight I hope to commit 4.10 port.
>>>>>>>>
>>>>>>>> It does not solve rhe pb, staying on the legacy libs is the
>>>>>>>> solution, as I
>>>>>>>> said even fedora is on the legacy
>>>>>>>>
>>>>>>> I've committed net/samba410.
>>>>>>>
>>>>>>> My view on the situation is that all the ports, which use
>>>>>>> devel/{talloc,tevent}, databases/tdb should keep
>>>>>>> using them, unless they are broken by using them(but that
>>>>>>> shouldn't happen,
>>>>>>> API still should remain
>>>>>>> the same. The biggest difference is the drop of the dependency on
>>>>>>> Python27,
>>>>>>> as far as I can see.
>>>>>>
>>>>>> So, branching 2019Q2 is now a day late.
>>>>>> When are you going to fix the issue?
>>>>>
>>>>> Mat, is this the reason the branch is late? If so: have you considered
>>>>> branching from r504589?
>>>>
>>>> It is being considered, yes, as a last resort kind of thing. timur@ has
>>>> had 13 days to fix the problem, I hope he is getting close to fixing it
>>>> all.
>>>
>>> It's probably time to introduce some sort of a soft freeze where no
>>> major changes are allowed (unless approved by portmgr) in the last two
>>> weeks or so of the quarter.  It's not just samba, x11@ moving the mesa
>>> ports to llvm80 on the last day of the quarter is also way too close.
>>>
>>
>> -1 on freezes, while I certainly understand the initial motivation for
>> something like that.
>>
>> 1) Quarterlies only gets a tiny proportion of bugfix commits merged from
>> the latest branch, so quarterly misses out on the vast majority of
>> bugfixes, except for the first week of the new quarter while everyone is
>> keen.
>>
>> 2) Anything that slows down or blocks development is a dealbreaker.
>> While I understand and agree that quality outweighs performance, we have
>> enough issues affecting productivity/cadence. We need both.
>>
>> 3) portmgr and ports-secteam are going to struggle to handle more
>> workloads.
>>
>> 4) Vesting more power and responsibility in centralized and opaque
>> structures takes away the ability of the project to scale, and is
>> difficult to revert once established. We need to get better at doing
>> things as a group, without requiring someone to tell us yes or no.
>>
>> 5) "major changes" is easy for the obvious cases, but not so much for
>> the rest. There are plenty of so called 'trivial' changes that cause
>> widespread regressions, sometimes not so obvious, and sometimes not
>> resolved until much later. Should no updates to any port that has more
>> than X dependencies occur in the last Y period of the quarterly window?
>> What if its a bugfix release? What if its a security release?
>>
>> The notion that quarterly is stable by way of the "lack of commits"
>> needs to be replaced with the understanding stable means "lack of bugs"
> 
> But it is stable in means of "lack of commits"? Most updates which are
> purely security or bugfixes are not MFHed. Sometimes feature-updates are
> needed to keep the software usable (like youtube_dl). I currently have a
> bunch of software getting the latest version from HEAD into my working
> copy in order to stay save. Getting fixes into quarterly is tedious and
> slow. Also the process is not well understood by all.

You're saying the same thing I am (I believe). That 'stable', contrary 
to how its currently perceived and treated, *should not* mean "lack of 
commits" , but instead mean "lack of bugs", as in "bugs get fixed".

Changing that perceptions starts with portmgr/ports-secteam 
communicating that clearly:

"All bugfixes should be merged. This includes ports (not just software) 
bugfixes. If you can, PLEASE ALSO merge other non-feature changes, like 
ports compliance changes, etc because this makes future merges easier"

Yes, most bugfixes and security commits don't get merged, with security 
updates doing marginally better. There's now a non-trivial amount of 
work being done now managing and assessing bug reports for 
quarterly-only issues, only to discover they've been fixed in head and 
not merged.

Merging is not *that* tedious, but it could be better, and it gets 
easier the more merges you do, especially when it comes to conflicts 
(caused by missing intermediate, non merged commits). If everyone had 
the latest quarterly checkout in development, that would reduce 
substantially the time it takes to merge.

Yes the process is not well understood by all, but this is a natural 
outcome of people avoiding the process, because its not entirely clear 
what the point is, because the messaging has been unclear from the 
start. We still have veteren developers asking what should and shouldn't 
be merged. This is the most obvious sign of a knowledge and/or 
expectations gap.

Target state:

1) Default merge policy, unless excluded (feature/version updates)
2) Explicit MFH: No's in commit log messages
3) Have a bot try to merge all commits without MFH: No
3.1) If it fails, email the committer ask them to merge manually cc 
ports-secteam. Maybe it cant be.
3.2) If it succeeds
4) Profit.

If we're afraid of what accidentally omitting "MFH: No" in commit log 
messages might mean, let's also solve *those* QA/process problems.

Being scared of the problems we'll run in to if we do certain things, 
will only mean we never solve those problems.

> Beside this you make some good points i really support!
> 
> Greetings,
> Torsten
> 
> 
>> We should instead be working on strategies and programs to get the most
>> developers leveled up on QA, making failure fast, *and* (very) cheap,
>> and making sure that most if not all bugfixes are *actually* merged.
>>
>> ./koobs
>>