[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Adding new game packages to Lenny



On Tue, Dec 30, 2008 at 10:26:29AM +0100, Gerfried Fuchs wrote:
> * Sylvain Beucler <beuc@beuc.net> [2008-12-30 08:40:10 CET]:
> > > They will not, and a good thing also.
> > > 
> > > The risks associated with this are way too large.
> > 
> > Hmm, what kind of risk?
> > 
> > I'm not suggesting to upgrade GCC, but to add independent packages
> > without reverse deps :)
> 
>  Even those can affect the overall stability of the system, have
> side-effects on unrelated packages that aren't properly checked (needed
> Conflicts, filename clashes, maintainer script woes)

It's beginning to make sense.
Can you explain "needed Conflicts"?

I think there's a problem when new packages also adds new RC bugs,
thus delaying the release. But in that case we could just drop the new
packages.


> > > Also, that's what a freeze is for: not allowing new stuff.
> > 
> > Well, in Fedora you can retro-add packages to the last 2 releases
> > pretty easily, so it can't be this bad ;)
> 
>  Please don't apply other distribution's doings to Debian, they have
> completely different approaches, like for a start to a security point of
> view of not doing just the bugfix but pulling in the new versions
> regularly, breaking interfaces along that path. You can't compare such
> things, Debian has a policy (and that's a good thing, most of the
> times).
> 
> > > ...but once Lenny releases, there is always the backports project[0],
> > > which is almost as good as getting it in to the main release :)
> > 
> > Yes, I plan to do this :) The problem is the "once Lenny releases"
> > part, since until then, backports is frozen too in this regard.
> 
>  .. or rather not opened for lenny-backports yet. etch-backports isn't
> frozen, but it still applies the same rules of accepting versions from
> lenny, which is propably what you mean.
> 
> > The fact Synaptic doesn't have an easy way to install backports makes
> > it pretty much unusable for normal (i.e. non-command-line-savvy,
> > i.e. our target) users too :/
> 
>  That might be the case now but I'm still confident that this will
> change over time when backports finally became an official ressource.

We'll definitely have a solution by Lenny+1 - including the fact that
our new packages will probably be integrated by then :)

But do we have solutions for people to simply install those new
packages? (aside from using another distro)

Let's not disregard solutions just because they come from other
distributions. I didn't even know some distros could retro-add
packages until I added my package to Fedora a couple months ago - and
I'm pretty pleased with that process so far.

This is apparently a matter of risk, similar to the risk of releasing
with a RC bugs count > 0. So there's probably matter for discussion:

Currently I highly doubt adding 'ballz' or 'freedink' to Lenny will
cause any breakage - so either I'm wrong, and I'm interested in
knowing why, either I'm right and it's a matter of Policy, in which
case the Policy can be improved.


> > Yeah, maybe it's a bit late - though in this regard I have a question:
> > in the last debian-devel-announce you read:
> > 
> >   "unblock requests sent after d-i RC2 will only be considered if they
> >   fix RC bugs, and nothing else."
> > 
> > Well, I thought this was the case since Jul 27 :( Do we have a "light
> > freeze" and "real/deep freeze"? It's gonna help me for next time.
> 
>  Adding new packages was the case since Jul 27th. It's just that
> important bug fixes (and in some cases normal ones too) were able to get
> unblocked too. From the release of d-i RC2 on it will be limited to RC
> bug fixes. That has no change or effect on new packages at all.

Is there some documentation about these different states of the
freeze, or was it some dynamic decision (i.e. not the standard
procedure)?

Thanks,

-- 
Sylvain


Reply to: