[Proposal] Samba 3.2.0 to replace 3.0.22
Gerald (Jerry) Carter
jerry at samba.org
Mon Jan 9 15:18:06 GMT 2006
-----BEGIN PGP SIGNED MESSAGE-----
James Peach wrote:
> Which of these result in incompatible changes with 3.0.*?
It's volker work that is of main concern. But we could
just ve acting paranoid. There's a couple of corner cases
where a simple 'rpm -Uvh samba*rpm' would be hard to
guarantee a working upgrade.
> So you are proposing to autogenerate more IDL interfaces
> than just DFS?
Yes. All of it.
> By "sweeping", do you mean "incompatible" or just "large"?
> I would say that incompatible changes could be a good
> rationale for bumping the minor version, but would have to
> be convinced otherwise.
Very large changes.
> Frankly, I don't know whether SGI would ship a 3.0 release
> and a 3.2 release on IRIX/Origin. I can't speak for SuSE,
> but this would certainly complicate my life supporting
> Samba on SLES/Altix if SuSE chose to ship 3.0 and 3.2
The more I think about it, the less the 3.2 idea appeals
to me. From a developer viewpoint, it's the easy way out.
- From a release perspective, I'm not so sure.
So I'm looking for advice. We have a large number of
changes. One of which has some nasty corner cases that we
want to get away from eventually anyways. So the concern
is about destabilizing the production code or falling into
the huge delay between release zone.
Here's the specifics of Volker's changes as I understand
them. The new code places unmapped groups into the new
internal domain. This can potentially break any security
descriptor on a file that has been created under POSIX
and copied to an NTFS drive since we previously applied
an RID algorithm to such unmapped groups.
Of course, one possibility to solve this is to create a
static mapping for such groups via and upgrade script,
> Given we already have less testing coverage than we would like,
> splitting our user community into 3.0 and 3.2 is a difficult
> decision. For how long would we support 3.0.*?
Our development model seems to follow current code. The
current code is always supported and people loose interest
in the older code. We can somewhat get away with this
when talking about 3.0.2a vs. 3.0.21a but forcing people
to upgrade from 3.0 to 3.2 is a harder sell (even so to
get vendors to ship a new upgrade).
> I don't see any problem in changing behaviours radically
> within the 3.0 series, provided it is done in a compatible
> way. If this is not possible, then I'll come around to
> the 3.2 view.
I'm still tossing ideas over in my head hoping that others
will chime in as well. Thanks for the feedback.
Alleviating the pain of Windows(tm) ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"There's an anonymous coward in all of us." --anonymous
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the samba-technical