Date: Tue, 2 Jul 2019 22:53:31 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: =?UTF-8?Q?T=c4=b3l_Coosemans?= <tijl@FreeBSD.org> Cc: ports-committers@freebsd.org, svn-ports-all <svn-ports-all@freebsd.org>, svn-ports-head <svn-ports-head@freebsd.org> Subject: Re: svn commit: r504590 - in head/net: samba46 samba47 samba48 Message-ID: <122bd115-6a91-bf50-f23a-75871d193cb7@FreeBSD.org> In-Reply-To: <20190702142827.120588a0@kalimero.tijl.coosemans.org> References: <201906192240.x5JMequU017187@repo.freebsd.org> <20190628070305.eim4o3d77iyti5d5@ivaldir.net> <20190629160445.051f2426@kalimero.tijl.coosemans.org> <CALdFvJHK0aBF6oLTFNnTiUyrmFUHCPYm3-k7S3_-FpYTHW4WSA@mail.gmail.com> <F208C261-18D8-4E5A-BABE-A9E6D8A52B5B@FreeBSD.org> <CALdFvJENynqPAkKSf5ueuG2nBMr9tckikzZOQv9caXtgcwZg4A@mail.gmail.com> <20190702102316.wv6w5u2ilfaw6vrd@atuin.in.mat.cc> <d9d37be2-8279-af6a-1283-67f25f4f8835@toco-domains.de> <20190702111647.vozqzf4gnqbajvcl@atuin.in.mat.cc> <20190702142827.120588a0@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/07/2019 10:28 pm, Tijl Coosemans wrote:
> On Tue, 2 Jul 2019 13:16:47 +0200 Mathieu Arnold <mat@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@freebsd.org> wrote:
>>>>>> Le 29 juin 2019 20:40:53 GMT+02:00, "Timur I. Bakeyev" <timur@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"
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?122bd115-6a91-bf50-f23a-75871d193cb7>