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