Bug 10309 - Fix a bunch on issues in the build
Fix a bunch on issues in the build
Status: RESOLVED WONTFIX
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Build
4.1.2
All All
: P5 normal
: ---
Assigned To: Andreas Schneider
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-06 08:44 UTC by Andreas Schneider
Modified: 2014-04-16 15:05 UTC (History)
0 users

See Also:


Attachments
v4-1-test patch (22.88 KB, patch)
2013-12-06 08:44 UTC, Andreas Schneider
obnox: review+
vl: review-
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schneider 2013-12-06 08:44:17 UTC
This patchset fixes build warnings, dead code and memory leaks in Samba.
Comment 1 Andreas Schneider 2013-12-06 08:44:57 UTC
Created attachment 9510 [details]
v4-1-test patch
Comment 2 Volker Lendecke 2013-12-06 09:00:41 UTC
Do we really need all of them in a release? I do see the memleak in production code like smbget or get_dc_ip, but the others are only in test code. I'd like to keep the release diffs small if there's no real requirement that comes from production code problems.
Comment 3 Andreas Schneider 2013-12-06 09:59:00 UTC
I could only fix them in our RPM, but I prefer to not carry around patches which are not in the upstream branch. They popped up cause our internal tools found the issues and I would like to silence them.
Comment 4 Michael Adam 2014-04-11 12:35:37 UTC
Comment on attachment 9510 [details]
v4-1-test patch

I generally understand Volker's concern. The memleaks are for granted, although I find such a collection bug "fix a bunch of this and that" slightly problematic. Nevertheless, ok for this time.

Most of the other fixes are in test code. So since this does not increase the diff in the production code unneccessarily, you get my ACK... ;-)
Comment 5 Volker Lendecke 2014-04-11 12:52:54 UTC
Comment on attachment 9510 [details]
v4-1-test patch

-1ing this: We need a discussion how to deal with absolutely non-production critical patches. Our downstream distros should be able to pretty much trust us to just fix critical bugs within a release stream. This patchset requires every OEM to go through much more stuff than strictly necessary. I'll take back that -1 after a public discussion about this topic.
Comment 6 Michael Adam 2014-04-11 14:05:07 UTC
(In reply to comment #5)
> Comment on attachment 9510 [details]
> v4-1-test patch
> 
> -1ing this: We need a discussion how to deal with absolutely non-production
> critical patches. Our downstream distros should be able to pretty much trust us
> to just fix critical bugs within a release stream. This patchset requires every
> OEM to go through much more stuff than strictly necessary. I'll take back that
> -1 after a public discussion about this topic.

Fair enough.

I think Volker has some good points here.
We should discuss and agree upon a policy for
bugfix releases more precise than just "we need a bug".

What is it that we want to achieve?
Volker's position is to bring in only the strictly necessary patches,
and there are some very good reasons for this.

Probably we have two motivations:

1. A distributor will be interested in keeping the diff
   between upstream released code and his version small.

2. Samba.org is (or should be, according at least to Volker
   and subject to discussion) interested in keeping the diff
   between the initial release of a bugfix release stream
   (in this case 4.1.0) and the next version (4.1.NEXT) small.

So with the samba-team hat on, we should indeed argue to keep
the torture fixes out of the release, because they are not
generally necessary, and while harmless for production still
clobber the diff and history and are also generally irrelevant
for the release.

Where do we go from here?

Michael
Comment 7 Andreas Schneider 2014-04-16 08:02:23 UTC
Closing as wontfix ... :)
Comment 8 Volker Lendecke 2014-04-16 15:05:30 UTC
(In reply to comment #7)
> Closing as wontfix ... :)

That's not what I had in mind. I wanted clarification from the Samba Team about its approach to dot-releases. I am fine with porting back anything, as long as the Samba Team decides that this is what is wanted.