Blockers in Bugfix-Releases (Re: [Release Planning 3.6] Samba 3.6.6 on May 31 (was May 24)?)
Andrew Bartlett
abartlet at samba.org
Sat Jun 9 18:35:44 MDT 2012
On Sat, 2012-06-09 at 16:39 +0200, Karolin Seeger wrote:
> Hi Andrew,
>
> On Fri, Jun 08, 2012 at 08:07:06AM +1000, Andrew Bartlett wrote:
> > What can we do to make this less time consuming? I know security
> > releases are a particular pain, but what about normal releases - is
> > there anything in that process we could simplify or automate to make
> > that simpler?
>
> security releases are more time-consuming, because of the numerous release
> branches. The usual release process is automated as far as possible, I
> think. Writing the release notes and publishing the news are the most
> time-consuming tasks and there is not much space for automation, I think
> (yes, some projects can automatically create release notes, but that would
> never work for the Samba Team IMHO).
>
> > > Additionally, another issue popped up and came across the release
> > > planning. But you are aware of that. Very unusual cricumstances.
> > >
> > > So you guys want to ship bugfix releases with severe known issues?
> > > That might work with more developers working on bugs on a regular basis.
> > > Currently, it does not. There are severe bugs that need to be addressed
> > > before the next bugfix release. Otherwise, they would never be addressed.
> > > IMHO blockers are needed to create a certain pressure.
> >
> > Does it really work like that?
> >
> > That is, does the threat that the release might be delayed create enough
> > pressure that issues are actually addressed, or does it just penalise
> > our other users because not addressing it 'just' means that we keep
> > delaying releases?
>
> Usually, it helps to raise the issues on the list and issues were not
> addressed, because nobody was aware of them (assigning in Bugzilla usually does
> not help for some people). I don't think that we penalise other users, but
> try to ship stable releases.
I'm not against shipping stable releases, and I am for constantly
improving the software we ship. But for me that means that if a release
is an improvement, then we should make it.
Developers should be tapped on the shoulder, reminded about bugs etc,
but that should be it. A release should not be delayed unless it would
contain a regression from the previous point release (see below on
regressions)
> > If an issue is severe, then it should deserve attention on it's own, and
> > missing the release entirely is our penalty.
> >
> > > Of course a release should not be delayed due to minor issues. If that
> > > ever happened, please let me know.
> >
> > As per our other discussion, I think we have terrible trouble defining
> > minor/major. For each of us, particularly after spending days chasing
> > difficult issue, our particular bug is usually a major issue.
>
> I am trying to ask the developers "hey, what exactly does not work for
> users without your patch(es), use children's language". From my point of view,
> that's one of the advantages when the release manager is not a developer.
> If basic features do not work, it's a major issue. If e.g.a VFS module has a
> problem, it's certainly not a major issue.
I don't think we should use the language of 'major issue'. It isn't the
right test. We should say "hey, what exactly does not work for users
without your patch(es), compared with the previous point release, use
children's language"
> > I would much rather use 'regression' as the definition - that is much
> > easier to pin down.
>
> My problem with the 'regression' is the following. A regression since
> when? 3.0? If in 3.6.6 joining of XP clients does not work, it's a
> regression compared to 3.0.x, but if it has never worked since 3.6.0, it's
> not a regression compared to 3.6.0, but it's definately a major issue from my
> point of view
> and I would try to grab one developer to get that fixed before the next
> bugfix release.
This is actually a prefect example. The issue is serious, but by
blocking a release waiting for a fix (or confirmation of a fix) for this
issue, we have denied users access to a stable release for non-DC
environments (or environments with the 'right' length hostnames - it was
an odd/even issue).
This is important, particularly as we move to Samba 4.0 with a much
larger codebase. The failure to join to an S3 DC has been with us since
before 3.6.0, so a release without that fix would by definition be no
worse than 3.6.0 or any subsequent point release. Therefore we should
make the release.
The same *will* happen with Samba 4.0. The new AD DC will not be
released perfect - no software ever is - but if we apply this test, then
bugs in the AD DC (and it's complex code, there is a good chance of some
quite serious issues despite our good results so far) will hold up file
server users from getting releases. This would not be a good thing!
So far, due to these delays, our 3.6 users are still waiting for fixes
for:
+o Michael Adam <obnox at samba.org>
+ * BUG 8738: SMB2 server will not release unused shares.
+ * BUG 8749: Sign non guest sessions in SessionSetup.
+ * BUG 8921: Fix race writing registry values.
+
o Jeremy Allison <jra at samba.org>
+ * BUG 8723: Add pthread-based aio VFS module.
+ * BUG 8784: When calculating the share security mask, take
priviliges into
+ account for the connecting user.
+ * BUG 8837: Fix crash in smbd when deleting directory and veto
files are
+ enabled.
+ * BUG 8857: Setting traverse rights fails to enable directory
traversal when
+ acl_xattr in use.
+ * BUG 8897: Make winbind_krb5_locator not only returning one IP
address.
+
+
+o Christian Ambach <ambi at samba.org>
+ * BUG 8406: Fix a return code check in Winbind.
+ * BUG 8807: Fix crash in dcerpc_lsa_lookup_sids_noalloc() crashes
when
+ groups has more than 1000 groups.
+
+
+o Andrew Bartlett <abartlet at samba.org>
+ * BUG 8599: Only use SamLogonEx when we can get unencrypted session
keys.
+ * BUG 8727: Fix smbclients with posix large reads.
+
+
+o Björn Baumbach <bb at sernet.de>
+ * BUG 7564: Fix default name resolve order in the manpage.
+ * BUG 8554, 8612, 8748: Add new printers to registry.
+ * BUG 8789: Remove whitespace in example samba.ldif.
+
+
+o Alejandro Escanero Blanco <aescanero at gmail.com>
+ * BUG 8798: The primary rid should be in the groups rid array.
+
+
+o Ira Cooper <samba at ira.wakeful.net>
+ * BUG 8729: Fix getpass regressions on Solaris/Illumos.
+ * BUG 8743: Fix configure.developer builds on Solaris.
+
+
+o David Disseldorp <ddiss at samba.org>
+ * BUG 8762: Fix crash in printer_list_set_printer().
+
+
+o Olaf Flebbe <o.flebbe at science-computing.de>
+ * BUG 8859: Fix assertion in reg_parse.
+
+
+o Björn Jacke <bj at sernet.de>
+ * BUG 8869: Remove outdated netscape ds 5 schema file.
+
+
+o Steve Langasek <steve.langasek at ubuntu.com>
+ * BUG 8920: Fix null dereference in pdb_interface.
+
+
+o Volker Lendecke <vl at samba.org>
+ * BUG 8567: Fix segfault in dom_sid_compare.
+ * BUG 8733: Delete streams on directories (streams_depot).
+ * BUG 8760: Add SERVERID_UNIQUE_ID_NOT_TO_VERIFY.
+ * BUG 8836: Fix segfaults on "smbcontrol close-share" in aio_fork.
+ * BUG 8861: Fix a segfault with debug level 3 on Solaris.
+ * BUG 8904: Fix Winbind crash triggered by 'wbinfo --lookup-sids
""'.
+
+
+o Stefan Metzmacher <metze at samba.org>
+ * BUG 8139: Ignore SMBecho errors (the server may not support it).
+ * BUG 8527: db_ctdb_traverse fails to traverse records created
within the
+ current transaction.
+ * BUG 8739: Fill the sids array of the info in
+ wbcAuthUserInfo_to_netr_SamInfo3().
+ * BUG 8749: Sign non guest sessions in SessionSetup.
+
+
+o Matthieu Patou <mat at matws.net>
+ * BUG 8599: Set the can_do_validation6 also for trusted domain.
+ * BUG 8734: Don't try to do clever thing if the username is not
found while
+ authenticating through Winbind.
+ * BUG 8771: Winbind takes up to 20 minutes to change from DC 1 to
DC 2.
+
+
+o SATOH Fumiyasu <fumiyas at osstech.co.jp>
+ * BUG 8826: Prepend '/' to filename argument (docs).
+
+
+o Richard Sharpe <realrichardsharpe at gmail.com>
+ * BUG 8768: Honor SeTakeOwnershipPrivilege when file opened with
SEC_STD_WRITE_OWNER.
+ * BUG 8797: Correctly handle DENY ACEs when privileges apply.
+ * BUG 8822: Fix building out-of-tree modules.
+
+
+o Simo Sorce <idra at samba.org>
+ * BUG 8915: Fix pam_winbind build against newer iniparser library.
+
+
+o Joseph Tam <jtam.home at gmail.com>
+ * BUG 8877: Syslog broken owing to mistyping of
debug_settings.syslog.
+
+
+o Ralph Wuerthner <ralph.wuerthner at de.ibm.com>
+ * BUG 8845: Move print_backend_init() behind init_system_info().
Should we deny our users all these fixes, because we want to get in one
more fix? Instead of saying 'these serious issues remain unresolved' in
a WHATSNEW of a release fixing all these other things, we are saying
'these serious issues remain unresolved, so you can't have a release at
all!'
Beyond individual users (who could go to GIT if they really wanted)
there are other costs to constantly slipping. For distributions, in the
thread on changing the stable branch rules Christian PERRIER
<bubulle at debian.org> said:
>
> Next Debian stable should be frozen "Quite Soon". We hope we'll be
> able
> to get 3.6.6 in before that (which is why the delay in that release
> saddens me, though I understand the reasons).
So, particularly if we keep slipping, the risk is that we deny all these
fixes to Debian stable users (they won't backport this many patches),
because of a serious issue hitting only the DC case that could actually
be backported.
So, what I'm saying is that unless a release would be measurably worse
than the minor release which it replaces, it should be shipped
regardless. We can then follow up with an ever better release next time
- quite soon if the fix warrants it.
Thanks,
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical
mailing list