Date: Tue, 2 Jul 2019 17:15:59 +0200 From: Torsten Zuehlsdorff <freebsd@toco-domains.de> To: koobs@FreeBSD.org, =?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: <2f784971-9a27-d904-4d04-52a620db0a3e@toco-domains.de> In-Reply-To: <122bd115-6a91-bf50-f23a-75871d193cb7@FreeBSD.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> <122bd115-6a91-bf50-f23a-75871d193cb7@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02.07.19 14:53, Kubilay Kocak wrote:
> 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"
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.
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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2f784971-9a27-d904-4d04-52a620db0a3e>