samba - Aug 2020 - getting (FreeBSD port) patches upstream first

On Tue, 2020-08-25 at 14:12 -0400, Andrew Walker via samba
wrote:
> On Tue, Aug 25, 2020 at 1:17 PM James B. Byrne via samba <
> samba at lists.samba.org> wrote:
> 
> > 
> > 
> > On Mon, August 24, 2020 22:19, Andrew Bartlett wrote:
> > 
> > > 
> > > A bit of an aside, but it would be incredibly awesome if the
> > > FreeBSD
> > > port could adopt the same policy as, eg, Debian and not ship any
> > > patches that are not upstream.
> > > 
> > I believe that Timur has indeed submitted patches of this nature. 
> > 
> 
> Timur did attempt to upstream the talloc patch here:
> https://lists.samba.org/archive/samba-technical/2018-February/125592.html
I've looked this over, and this is exactly the right example, as it
happens.  There was a great discussion about the patch, and ultimately
it was rejected.

This is good feedback, and should not have been ignored in my view. 
Note that I said 'are not upstream', not 'have not been submitted
upstream'.

The gap between those two things ends up being the issue here, which is
when patches we (as the Samba Team) don't agree with are still applied
by distributors and porters, all the QA, experience etc applied to
Samba.org releases is just discarded.

It also just makes bug triage much harder, and we have seen here that
triage of FreeBSD issues is hard enough right now.

Now of course there are always matters of degree in this, but is is an
important principle to start with.

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT - Expert Open Source
Solutions
https://catalyst.net.nz/services/samba

On Tue, August 25, 2020 21:11, Andrew Bartlett wrote:
> On Tue, 2020-08-25 at 14:12 -0400, Andrew Walker via samba wrote:
>> On Tue, Aug 25, 2020 at 1:17 PM James B. Byrne via samba <
>> samba at lists.samba.org> wrote:
>>
>> >
>> >
>> > On Mon, August 24, 2020 22:19, Andrew Bartlett wrote:
>> >
>> > >
>> > > A bit of an aside, but it would be incredibly awesome if the
>> > > FreeBSD
>> > > port could adopt the same policy as, eg, Debian and not ship
any
>> > > patches that are not upstream.
>> > >
>> > I believe that Timur has indeed submitted patches of this nature.
>> >
>>
>> Timur did attempt to upstream the talloc patch here:
>>
https://lists.samba.org/archive/samba-technical/2018-February/125592.html
>
> I've looked this over, and this is exactly the right example, as it
> happens.  There was a great discussion about the patch, and ultimately
> it was rejected.
>
> This is good feedback, and should not have been ignored in my view.
> Note that I said 'are not upstream', not 'have not been
submitted
> upstream'.
>
> The gap between those two things ends up being the issue here, which is
> when patches we (as the Samba Team) don't agree with are still applied
> by distributors and porters, all the QA, experience etc applied to
> Samba.org releases is just discarded.
>
> It also just makes bug triage much harder, and we have seen here that
> triage of FreeBSD issues is hard enough right now.
>
> Now of course there are always matters of degree in this, but is is an
> important principle to start with.
>
> Andrew Bartlett
>
I am not arguing for or against anyone's position on this.

Without those patches Samba will not provision as an AD-DC on FreeBSD.  The
choice for users of FreeBSD therefor is between something that works, and is
deprecated upstream, or nothing at all.

Regards,

-- 
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
   Unencrypted messages have no legal claim to privacy
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

On Wed, Aug 26, 2020 at 9:53 AM James B. Byrne <byrnejb at harte-lyne.ca>
wrote:
>
>
> On Tue, August 25, 2020 21:11, Andrew Bartlett wrote:
> > On Tue, 2020-08-25 at 14:12 -0400, Andrew Walker via samba wrote:
> >> On Tue, Aug 25, 2020 at 1:17 PM James B. Byrne via samba <
> >> samba at lists.samba.org> wrote:
> >>
> >> >
> >> >
> >> > On Mon, August 24, 2020 22:19, Andrew Bartlett wrote:
> >> >
> >> > >
> >> > > A bit of an aside, but it would be incredibly awesome if
the
> >> > > FreeBSD
> >> > > port could adopt the same policy as, eg, Debian and not
ship any
> >> > > patches that are not upstream.
> >> > >
> >> > I believe that Timur has indeed submitted patches of this
nature.
> >> >
> >>
> >> Timur did attempt to upstream the talloc patch here:
> >>
> https://lists.samba.org/archive/samba-technical/2018-February/125592.html
> >
> > I've looked this over, and this is exactly the right example, as
it
> > happens.  There was a great discussion about the patch, and ultimately
> > it was rejected.
> >
> > This is good feedback, and should not have been ignored in my view.
> > Note that I said 'are not upstream', not 'have not been
submitted
> > upstream'.
> >
> > The gap between those two things ends up being the issue here, which
is
> > when patches we (as the Samba Team) don't agree with are still
applied
> > by distributors and porters, all the QA, experience etc applied to
> > Samba.org releases is just discarded.
> >
> > It also just makes bug triage much harder, and we have seen here that
> > triage of FreeBSD issues is hard enough right now.
> >
> > Now of course there are always matters of degree in this, but is is an
> > important principle to start with.
> >
> > Andrew Bartlett
> >
>
> I am not arguing for or against anyone's position on this.
>
> Without those patches Samba will not provision as an AD-DC on FreeBSD.  The
> choice for users of FreeBSD therefor is between something that works, and
> is
> deprecated upstream, or nothing at all.
>
> Regards,
>
>
> The last time I checked, the patches necessary for ZFS-backed sysvol for
AD DC were relatively minor. I can double-check on master and make an
appropriate MR when I have time. This is one of the things that has gotten
much better in the past year or so (making merge requests through
gitlab).
>From an external standpoint, upstreaming fixes is a much clearer process
than it used to be.