(sorry, long reply....but it contains many ideas about handling stable releases both for distros and for upstream software...That answer is BCC'ed to our package development list)
Quoting Jeremy Allison ([EMAIL PROTECTED]): > As you wish, but there are several significant bugs > (with printing for one) that have been fixed for the > 3.2.1 release. Yeah. I definitely know that. But, in that case, I'm just one of the dozens Debian developers and I have no power to enforce a new release of my pet software in Debian stable if this is something that's not "allowed" by our work method. Other vendors do indeed the same choice when they freeze a release of theirs. They're maybe less strict in the way they freeze software versions...or often provide updated packages for their stables releases as a service to their customers. Or maybe they're just not as big as Debian is...:-) (I mean when it comes at the number of proposed software....) The difference lies there: commercial vendors *can* afford to spend some resources in doing this (or in doing *design choices* to limit the scope of what they support and what they do not support). Debian developers only rely on themselves and the volunteer resources to do that. Indeed, Debian has such service, namely backports.debian.org, which is a non-official service from the project where some motivated developers provide up-to-date packages for Debian stable. If we (the maintainers of samba in Debian) have enough time for this, we might do it.....The main problem is that both "main" maintainers of samba in Debian, namely Steve Langasek and myself, have many other commitments in Debian, that eat our time (which is only volunteer time). And, anyway, such backports are not as supported as stable versions are, particularly security-wise, of course. Here, I don't think you have something to learn from me, Jeremy, of course...:-) If we could commit ourselves to release backported packages at the same rhythm you guys are releasing upates, that would be OK, still... > > You have to start thinking of Samba as the Linux kernel, > we are now on a 6-monthly upgrade cycle, with minor bugfixes > inbetween every 2 months or so. That's something we could actually discuss with some of the Stable Release Managers in Debian, indeed. Maybe you're not aware of this but we recently introduced, in Debian Etch, the concept of "half" releases. "Etch and a half" was just released 2 weeks ago: it is an update of Debian Etch (which was out in April 2007) that contains an updated kernel and updated X.org packages, as well as an updated installer. That "etch and a half" release was aimed to answer the frequent problems of users having unsupported hardware. It *is* supported by our security team, contrary to backports.org packages. It would maybe be pushed a little by providing updates for some "key" packages (problems: "define key"...every Debian developer will want to include his|her pet package there!). > > Remember, most people didn't test 3.2.0 at all before it > was released, so I'm actually quite pleased with the > quality of the release (congratulations to Karolin for > that !), but there are several issues that need a bugfix. Another way to go should probably be to provide updated .deb packages for Debian stable, and the LTS Ubuntu versions, on samba.org... This was one of the reasons I began working on our (Debian) packaging *and* packages provided by Sernet (which were at that time the closest thing to "genuine" packages) to make them converge together, back in April 2008. Apart from the remaining few controversial changes needed (from our POV) for FHS compliance, that seemed to be fairly easy.....as long as someone with enough knowledge on .deb packaging takes a few days to re-work on these issues.... (/me wishes to have 36 hours per day) -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba