LTS-to-LTS Cycle Freezes: Transitions

[Steve Langasek]

On Sat, Feb 25, 2012 at 09:30:27PM -0600, Ted Gould wrote:
> On Sat, 2012-02-25 at 14:51 -0500, Scott Kitterman wrote:
> > On Saturday, February 25, 2012 01:42:51 PM Ted Gould wrote:
> > > Hmm, my understanding was that it was something in the Ubuntu policies
> > > and procedures.  I think it does effect things like derivatives, no?
> > > Anyone on the RT can approve MIRs, right?

> > No, there's a separate MIR approval team for that.  After Precise none of the 
> > other flavors will be in Main, so it won't matter.  For Precise and earlier 
> > Kubuntu would be affected, but it's status is changing, so it's only 
> > Ubuntu/Ubuntu Server that are at issue.

> Oh, okay, I didn't realize.  Do you then think that any potential policy
> should avoid talking about main and MIRs or it's just a "don't care"?

I think it's a grave mistake to try to dictate such a policy *except* in the
context of main.

First, most of the packages in universe are ones that we get for free from
Debian.  They require almost no upkeep and are almost never modified, but
provide value to our users by increasing the amount of free software
available by default on Ubuntu.  Requiring this software to be ported to the
toolkits and technologies that are on the roadmap for the default Ubuntu
install would simply result in a lot of this software being removed from the
release, making Ubuntu less useful *and* costing the archive admins a huge
amount of effort to filter our Debian syncs to comply with such a policy.

Second, Ubuntu is a cosmopolitan community, and there are several recognized
community flavors which for one reason or another have made different
technology choices than we make for Ubuntu (the images).  These flavors
should continue to have the freedom to make these different choices *within*
the framework of the Ubuntu archive, and not have the choice taken from
them, or the timeline dictated to them, based on the technology decisions
that have been made for main.

So while we could recommend particular technologies, it would be
counterproductive to mandate them for universe.  And we're already tacitly
recommending technologies by virtue of what we choose to include in the
default install.


For main, I certainly think it's an interesting idea to have this sort of
deprecation roadmap.  (And I don't agree with Scott that this would be a
Canonical-internal thing; while Canonical has some say in whether a package
can be in main because packages in main have to be supportable by the
security team, there are plenty of cases where particular software has been
nominated for main by other members of the community.)  I'm not too sure
about the mechanics though - is this really something we want to ask the MIR
team to have to keep track of?  They're stretched thin as it is.

> I think that there ends up a couple of classes of software, that which
> is well maintained and that which is maintained on life support.  Where
> it still exists and works, but it's not being kept up-to-date with all
> the recent changes in how a modern distro works.  This is defining a way
> to start removing things from the archives that are in that second
> category.

Again, this would be a huge increase in archive management costs for no real
benefit.

> Well, to be fully LSB compliant we'd have to switch to RPM as well ;-)

No, that's not what LSB means <grr>.  An LSB-compliant distribution only has
to support installing packages in the subset of the RPM format specified in
the LSB.

> I don't believe that LSB is a requirement that we've made for Ubuntu,
> but I can't find anything on that with a Google search.  Again, if that
> is a requirement the specific transitions here could be modified to take
> into account those requirements.

The LSB certification process has always been dysfunctional, expecting
distro vendors and OEMs to both pay for certification and thus utterly
failing to ever achieve a critical mass of either.  Debian and Ubuntu have
both had an lsb support package available for years that depends on the
corresponding system libraries and allow for installation of LSB packages by
way of 'alien' rpm->dpkg conversion.  I gather there are some printer driver
packages out there that make use of this, and I guess they work well enough
today.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120226/e36e8c18/attachment.pgp>