Andrew Bartlett
2020-Aug-26 01:11 UTC
[Samba] 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.htmlI'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
James B. Byrne
2020-Aug-26 13:53 UTC
[Samba] getting (FreeBSD port) patches upstream first
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 forAD 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 processthan it used to be.