Re: A new Priority level, ???backports??? ? (Re: unstable/testing/[pending/frozen/]stable)
On Fri, Oct 08, 2010 at 10:58:24AM +0900, Charles Plessy wrote:
> I was acually meditating on Joerg's answer for the past two weeks, wondering
> that if my some of my packages are bullshit, I should look for another place to
> distribute them instead of letting them be a burden for everybody.
I did not read any answer in the sense that some packages are a burden.
IMHO only those packages are a burden which are hanging around ages with
RC bugs or low popcon packages who are not maintained actively (and thus
might contain RC bugs but nobody notices).
> None of the packages I maintain can be described as being a integral part of an
> ???operating system???. None of them is essential to Debian.
We have a category "essential" but I do not think that this category
maps to what you mean with essential. It is hard to define what
building blocks are essentially for building an "universal operating
system" and thus we will probably run circles in deciding whether a
package is essential / needed / nice to have / whatever. IMHO, the most
important thing is that a package is properly maintained.
> Would a Debian PPA or
> a private repository be a better place for them? Personally, I do not think
> so.
I don't think so neither. In the sense of my paragraph above you can
not find a clear borderline what belongs to Debian and what not.
> I have embraced the ???Debian Pure Blend??? concept, which is to do our work in
> Debian, not as a supplement to Debian.
IMHO (for sure ;-)) this is a reasonable concept.
> Now that Debian has an official
> backports suite, I think that it can change the way we distribute our final
> products: packages that have demonstrated their quality by migrating and
> staying in Testing.
I do not really see in how far the existence of the official backports
suite should change the look onto Debian stable in general. I have
understood backports as an additional service to the existing stable and
not as a reason to drop packages from stable.
> > This whole thing does not make sense at all. Priority is the wrong knob.
>
> [???]
!!!
> The package priorities establish concentric subnetworks of our binary
> dependancy graph.
Yes.
> I think that it is an interesting property that is under-used.
I do not think so.
> Having a priority lower than extra would allow packages to coexist
> in Testing without interfering with Stable. They would have the same aims in
> terms of quality ??? that is the responsibility of the maintainer.
But why? I do not see a reason to have packages inside Debian which do
not "deserve" to end up in stable. Debian stable is THE PRODUCT we are
releasing, it is the goal we are working towards. There are people
relying on this product and I do not see any reason to exclude a set of
packages from stable.
> However, the lower-priority package would not pretend at the same durability,
> which is two to four years if we take the freeze and the Oldstable support in
> account. In two years, some packages that are currently in Squeeze will still
> be fine for most users, while for others, users interest for such an old
> version can be very low.
IMHO this paragraph just proves that the priority scale and the aging of
programs scale are orthogonal and priority is just the wrong knob.
There are people who are needing the latest postgresql,
open(libre?)office, firefox (for whatever reason) but none of these
packages would even go into the category extra. On the other end of
your arguing we have some scientific software which is not maintained
upstream any more, has low popcon but has some use for a certain amount
of users anyway and thus is maintained by Debian Med/Science team. From
a priority point of view they could qualify for "below extra". However,
these packages are completely wrong in backports because they are just
not updated by upstream any more.
So priority and actuality of a package are just different dimensions.
> For this, the maintainer sometimes can do little,
> apart from giving up packaging software from young projects.
Why? Having an old version in stable and having a more up to date
version in backports is the solution, isn't it?
> Although it is not a problem to release these packages in Stable, I think that
> ??? in the case of some packages I maintain in the Debian Med team ??? we would
> send a clearer message by distributing them to our Stable users only as
> backports. Without compromising on the quality.
If I would try to wear my users hat I would definitely not understand
your message. It's rather confusing than clear from my point of view.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: