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

Kubilay Kocak koobs at FreeBSD.org
Tue Jul 2 16:02:12 UTC 2019


On 3/07/2019 1:48 am, Alexey Dokuchaev wrote:
> On Wed, Jul 03, 2019 at 01:35:14AM +1000, Kubilay Kocak wrote:
>> ...
>> 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.
> 
> The correct way out of this mess is what had been said before on numerous
> occasion: stable/security/quarterly branches should be operated by ports-
> secteam@ or however it's called, not by the individual committers.  This
> would solve *all* the problems of what and how to merge because dedicated
> team would know better and coordinate its action only within itself.
> 
> ./danfe
> 

What and how to merge is obvious, it just hasn't been communicated 
effectively, consistently or clearly enough, unless individuals ask on 
their own accord, which benefits noone other than that individual.

Should we have a team (portmgr, other) that vets/blocks all commits to 
head to make sure they do the right thing, or they've been tested? No, 
that would be silly.

Not only does ports-secteam, or any other separate team not have an 
understanding of the commits/software/changes that the committer of that 
change presumably did, but they also couldn't scale effectively enough 
to do so even if we wanted them to. It's not ports-secteams job beyond 
cursory review/approval on security only changes. They have said this 
themselves.

Having a team that hardly has the resources to currently approve MFH 
requests in a timely manner, also have to manually merge things that 
developers ought to (and do) have the knowledge and ability to do 
themselves, is the exact opposite of the correct way forward, *if* we 
want any hope of quarterly actually becoming the thing we promised users 
it would be.


More information about the svn-ports-all mailing list