FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-31-2011, 02:55 PM
Michael Gilbert
 
Default Upstream "stable" branches and Debian freeze

On Mon, 31 Jan 2011 15:25:11 +0100, Max Kellermann wrote:
> Hi,
>
> I'm the upstream maintainer of the Music Player Daemon project, and
> receive a number of support requests / bug reports from Debian users
> who use the outdated version 0.15.12 of "mpd", currently in testing.
> These bugs were already fixed in newer maintenance releases.
>
> I know that Debian does not upgrade upstream versions at this point.
> However, I would like to know if upgrading within an upstream "stable"
> branch like MPD's v0.15.x would be acceptable.
>
> It seems common practice to cherry-pick upstream patches, and apply
> them to the old Debian package. That however seems like a waste of
> time, since all commits in our stable branch are bug fixes which would
> need to be picked, and in the end, you would essentially have version
> 0.15.15 which prints "0.15.12" on --version, just to fulfill Debian's
> policy.
>
> For me personally, this boils down to the question: shall I continue
> to maintain the old branch v0.15.x? (there is also v0.16.x which is
> also in maintenance mode)

It's too late now to make any changes for the initial squeeze release,
but you (or the Debian maintainer) can propose an update for 6.0.1,
which will be reviewed by the release team. If the changes have a low
chance of breaking things, which it sounds like in this case, they will
usually accept it.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110131105511.73108247.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110131105511.73108247.michael.s.gilbert@gmail.co m
 
Old 01-31-2011, 04:09 PM
Christian PERRIER
 
Default Upstream "stable" branches and Debian freeze

Quoting Max Kellermann (max@duempel.org):

> I'm the upstream maintainer of the Music Player Daemon project, and
> receive a number of support requests / bug reports from Debian users
> who use the outdated version 0.15.12 of "mpd", currently in testing.
> These bugs were already fixed in newer maintenance releases.
>
> I know that Debian does not upgrade upstream versions at this point.
> However, I would like to know if upgrading within an upstream "stable"
> branch like MPD's v0.15.x would be acceptable.


I have about the same concern for samba..:-)
(except that I'm not samba upstream as most people know...)

For the lenny release cycle, we (samba maintainers...indeed often me)
pushed several upstream fixes for bugs reported in Debian with severity
"important". This, in addition, of course, to the security fixes.

This has been accepted by the Stable Release Team in each case.

However, upstream's policy in their "stable" branches is alway to only
fix "important" bugs (they don't call them this way...but the
definition is fairly close to Debian's). So, *in the case of samba*, I
can guarantee that the user's (indeed sysadmin's) experience is much
improved if (s)he can follow the upstream minor releases.

So, I'm strongly considering asking the SRT if it would be OK to track
samba 3.5 branch along the life of squeeze (we'll be releasing with
samba 3.5.6).

This is certainly a trade-off to do on a case-by-case basis. In the
case of samba, I'm as certain as one can be that upstream's policy is
strict enough for me to more or less blindly follow them (particularly
just right now as samba 3.5 has aged enough in the Samba Team
barrels...;-)). The situation may be different for other upstreams, of
course.
 
Old 01-31-2011, 07:21 PM
Tollef Fog Heen
 
Default Upstream "stable" branches and Debian freeze

]] Samuel Thibault

Hi,

| His question could be rephrased: will the 6.0.x updates be allowed to
| pick up new upstream "stable" fixes releases?

While I can't speak for the release team (neither the stable or the
«regular» one), I know that postgresql stable releases are generally
allowed into new stable releases, since they're about as picky and
conservative as we are with regards to what the backport to their stable
branches.

So, I think this depends on what the policy for the upstream branch is.
If it's just important fixes, it might be. If it's a random mix of new
features, bug fixes and so on, it's less likely.

Best regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k4hk964c.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87k4hk964c.fsf@qurzaw.varnish-software.com
 
Old 02-01-2011, 08:12 AM
"Thijs Kinkhorst"
 
Default Upstream "stable" branches and Debian freeze

On Mon, January 31, 2011 18:09, Christian PERRIER wrote:
> However, upstream's policy in their "stable" branches is alway to only
> fix "important" bugs (they don't call them this way...but the
> definition is fairly close to Debian's). So, *in the case of samba*, I
> can guarantee that the user's (indeed sysadmin's) experience is much
> improved if (s)he can follow the upstream minor releases.

In the past such things have not been allowed with the argumentation that
even though stable may contain bugs, users rely on the behaviour that
stable has. They may know about a bug but may have worked around it (and
the update may break the workaround) or they do not know about a bug but a
fix for it may break a previously functional system. And of course as we
all know: bugfixes are not zero-risk and do have chances on new bugs being
introduced.

Being completely bug-free would be nice, but is probably unachievable. I
think there's something to say for the predictability of a release: it may
not be perfect, but once installed and tested it will keep working.


Cheers,
Thijs


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4edb1dc090de6330490ab7f897785b9f.squirrel@wm.kinkh orst.nl">http://lists.debian.org/4edb1dc090de6330490ab7f897785b9f.squirrel@wm.kinkh orst.nl
 
Old 02-01-2011, 10:41 AM
Henrique de Moraes Holschuh
 
Default Upstream "stable" branches and Debian freeze

On Tue, 01 Feb 2011, Thijs Kinkhorst wrote:
> On Mon, January 31, 2011 18:09, Christian PERRIER wrote:
> > However, upstream's policy in their "stable" branches is alway to only
> > fix "important" bugs (they don't call them this way...but the
> > definition is fairly close to Debian's). So, *in the case of samba*, I
> > can guarantee that the user's (indeed sysadmin's) experience is much
> > improved if (s)he can follow the upstream minor releases.
>
> In the past such things have not been allowed with the argumentation that
> even though stable may contain bugs, users rely on the behaviour that
> stable has. They may know about a bug but may have worked around it (and
> the update may break the workaround) or they do not know about a bug but a
> fix for it may break a previously functional system. And of course as we
> all know: bugfixes are not zero-risk and do have chances on new bugs being
> introduced.

It is a good thing that we are actually able to learn, and move forward
then, isn't it?

Some upstreams do so much regression testing and are so strict, that
you'd actually be doing a disservice to your users if you don't track
their stable branch during Debian stable lifetime.

> Being completely bug-free would be nice, but is probably unachievable. I
> think there's something to say for the predictability of a release: it may

You can just unplug it from the net and never update, if you want that
(and if you're going to do that, be smart and use read-only media for
the invariant parts of the system already): We've had several
regressions due to security fixes. While those are not frequent,
they're certainly not rare enough that you can ignore the fact.

We seem to have reached a good equilibrium of stability versus
bug-fixing on most packages. The current de-facto system works, let's
not mess with that.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110201114155.GB29264@khazad-dum.debian.net">http://lists.debian.org/20110201114155.GB29264@khazad-dum.debian.net
 
Old 02-01-2011, 12:11 PM
Ian Jackson
 
Default Upstream "stable" branches and Debian freeze

Thijs Kinkhorst writes ("Re: Upstream "stable" branches and Debian freeze"):
> In the past such things have not been allowed with the argumentation that
> even though stable may contain bugs, users rely on the behaviour that
> stable has. They may know about a bug but may have worked around it (and
> the update may break the workaround) or they do not know about a bug but a
> fix for it may break a previously functional system. And of course as we
> all know: bugfixes are not zero-risk and do have chances on new bugs being
> introduced.

Basically this argument is "the update may break things".

That's true, but the right questions are: how likely is that; how bad
are the bugs that would be fixed by the update; and so on.

> Being completely bug-free would be nice, but is probably unachievable. I
> think there's something to say for the predictability of a release: it may
> not be perfect, but once installed and tested it will keep working.

This argument seems very absolutist and would seem to suggest we
should never do any stable release updates at all. But a user who
wants that level of stability can simply not take the stable release
updates, and only apply the security updates.

I think there is room for us relaxing our policy for stable updates.
Where upstream have a good track record of not breaking their own
stable branch, I think providing those updates to our users is
probably sensible.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19784.1680.379747.405980@chiark.greenend.org.uk">h ttp://lists.debian.org/19784.1680.379747.405980@chiark.greenend.org.uk
 
Old 02-01-2011, 02:32 PM
Philipp Kern
 
Default Upstream "stable" branches and Debian freeze

On 2011-02-01, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> This argument seems very absolutist and would seem to suggest we
> should never do any stable release updates at all. But a user who
> wants that level of stability can simply not take the stable release
> updates, and only apply the security updates.

That's not easily possible as stable as found on the mirrors is overriden
by point releases.[1] So you'd need to mirror stable r0.

> I think there is room for us relaxing our policy for stable updates.
> Where upstream have a good track record of not breaking their own
> stable branch, I think providing those updates to our users is
> probably sensible.

First off they have to establish that track record with us, though.

(See also [2]. There will be a few updates to leaf packages in stable.
However updates to stable server software will be considered carefully,
and it depends on how we're convinced of the QA of maintainers and the
quality of upstream releases. PostgreSQL did that[3]. For others we'll
act on a case-by-case basis.)

Kind regards
Philipp Kern

[1] Ubuntu does it a tad differently. On normal releases their release suite
isn't updated. Instead updates are just pushed through the -updates suite.
So here you're free to ignore those. LTS do point releases like we do,
though.
[2] http://lists.debian.org/debian-volatile-announce/2011/msg00000.html
[3] And they better don't screw up...


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnikg9su.sv7.trash@kelgar.0x539.de">http://lists.debian.org/slrnikg9su.sv7.trash@kelgar.0x539.de
 
Old 02-01-2011, 03:09 PM
"Jesús M. Navarro"
 
Default Upstream "stable" branches and Debian freeze

Hi, Ian:

On Tuesday 01 February 2011 14:11:44 Ian Jackson wrote:
> Thijs Kinkhorst writes ("Re: Upstream "stable" branches and Debian freeze"):
> > In the past such things have not been allowed with the argumentation that
> > even though stable may contain bugs, users rely on the behaviour that
> > stable has. They may know about a bug but may have worked around it (and
> > the update may break the workaround) or they do not know about a bug but
> > a fix for it may break a previously functional system. And of course as
> > we all know: bugfixes are not zero-risk and do have chances on new bugs
> > being introduced.
>
> Basically this argument is "the update may break things".

[...]

> I think there is room for us relaxing our policy for stable updates.
> Where upstream have a good track record of not breaking their own
> stable branch, I think providing those updates to our users is
> probably sensible.

I don't think "relax" is the word but "reinterpret".

Why is the policy exactly the way it is? It's obvious that changes are
allowed as security and point releases show. The "why" is obvious too:
because security and/or severe malfunctions overweight the risk of breaking
things *and* Debian release/security team try to minimize that risk by
patching the bare minimum to achieve the intended result.

That said, I find that to be the proper way for a maintenance policy and an
interesting one to push forward to upstream maintainers: it's not Debian,
it's proper engineering to strictly segregate bug fixing from new
functionality; it's proper engineering comitting for long term maintenance
for selected versions of your software and it's proper engineering taking
responsibility for the software one publishes and the bugs that come along
with it.

So, may I propose (if not already done) a document that outlines with enough
detail what Debian maintenance policy is and why from an upstream point of
view, and then allow for within Stable upgrades for software that has
demonstrated to pursue the same standards as Debian? Kindof a "quality seal"
that will allow to push minor versions: it would mean "more with less" since
Debian maintainers wouldn't need to maintain their own patch sets and they
would know in advance what the "proper" version to pack for Stable is (the
one that upstream publishes for long term maintenance within the time-frame
for the new Stable version). For those upstreamers interested in doing the
things the proper way, they could find Debian people to be knowledgeable and
helpful about it (since they've been doing it for years and it's in their own
interest).

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201102011709.40161.jesus.navarro@undominio.net">ht tp://lists.debian.org/201102011709.40161.jesus.navarro@undominio.net
 
Old 02-01-2011, 03:18 PM
Olaf van der Spek
 
Default Upstream "stable" branches and Debian freeze

2011/2/1 Jesús M. Navarro <jesus.navarro@undominio.net>:
> So, may I propose (if not already done) a document that outlines with enough
> detail what Debian maintenance policy is and why from an upstream point of
> view, and then allow for within Stable upgrades for software that has
> demonstrated to pursue the same standards as Debian? *Kindof a "quality seal"
> that will allow to push minor versions: it would mean "more with less" since
> Debian maintainers wouldn't need to maintain their own patch sets and they
> would know in advance what the "proper" version to pack for Stable is (the
> one that upstream publishes for long term maintenance within the time-frame
> for the new Stable version). *For those upstreamers interested in doing the
> things the proper way, they could find Debian people to be knowledgeable and
> helpful about it (since they've been doing it for years and it's in their own
> interest).

It depends on the kind of package and computer whether it makes sense.
For production servers, stability is (way) more important.
For desktop users and packages like browsers, which might be fast
moving, new features might be more important.
Upstream for Firefox and Chrome are not going to provide stable
branches that are maintained for two+ years.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinOqYUc=G6GY9ckkJsGFkp6jzS8NxswS0QsTHNg@mail .gmail.com">http://lists.debian.org/AANLkTinOqYUc=G6GY9ckkJsGFkp6jzS8NxswS0QsTHNg@mail .gmail.com
 
Old 02-01-2011, 03:40 PM
"Jesús M. Navarro"
 
Default Upstream "stable" branches and Debian freeze

Hi, Olaf:

On Tuesday 01 February 2011 17:18:58 Olaf van der Spek wrote:
> 2011/2/1 Jesús M. Navarro <jesus.navarro@undominio.net>:
> > So, may I propose (if not already done) a document that outlines with
> > enough detail what Debian maintenance policy is and why from an upstream
> > point of view, and then allow for within Stable upgrades for software
> > that has demonstrated to pursue the same standards as Debian? *Kindof a
> > "quality seal" that will allow to push minor versions: it would mean
> > "more with less" since Debian maintainers wouldn't need to maintain their
> > own patch sets and they would know in advance what the "proper" version
> > to pack for Stable is (the one that upstream publishes for long term
> > maintenance within the time-frame for the new Stable version). *For those
> > upstreamers interested in doing the things the proper way, they could
> > find Debian people to be knowledgeable and helpful about it (since
> > they've been doing it for years and it's in their own interest).
>
> It depends on the kind of package and computer whether it makes sense.
> For production servers, stability is (way) more important.
> For desktop users and packages like browsers, which might be fast
> moving, new features might be more important.

It depends more on the use case than in the package. As long as there's no
interface with externals/third parties it makes more sense add new
functionality only as needed, no matter if it's a kernel or a web browser.

> Upstream for Firefox and Chrome are not going to provide stable
> branches that are maintained for two+ years.

That's up to them and, in fact, it makes no difference: they won't get
the "quality seal" and their maintenance procedures within Debian will be
just the way they are now so no loss from this side.

On the other hand, each and every package that would go under the "quality
seal" umbrella would mean an easier day for the package maintainer, a higher
quality software for everybody and, on a side note, source of "unintended"
benefits for everybody (remember Mark Shuttleworth's interest on sincronizing
packages among distributions? It would be a natural outcome if a significant
number of upstreamers aligned to the "quality seal" idea: distributions
interested on stability would just converge around the long term versions
distributed by upstream).

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201102011740.20430.jesus.navarro@undominio.net">ht tp://lists.debian.org/201102011740.20430.jesus.navarro@undominio.net
 

Thread Tools




All times are GMT. The time now is 09:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org