LTS-to-LTS Cycle Freezes: Transitions

[Ted Gould]

On Sun, 2012-02-26 at 16:53 -0800, Steve Langasek wrote:
> 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.

I think that the Open Source ecosystem is at the point where we're not
looking to encouraging more software, we're interested in encouraging
better software.  Just because something is easy to maintain, doesn't
mean it should be in the archive and easily installable for users.

I'm afraid that I don't quite understand the Debian sync issue, I
thought we only sync'd packages that we had in the archive.  It seems
like the only additional work would be removing packages that didn't
comply, and this could be done by looking at their dependencies.  As far
as adding new packages, it would get caught by the fact that there was
no way to achieve certain deps in that new package.

> 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.

I feel that in this case we're not "recommending technologies" what
we're doing is pushing along well documented transitions from the
upstream sources.  Where, if they're not done, the software is at some
level in an unsupported state.  I can, for instance, guess the amount of
attention that a critical GConf bug is going to get in GNOME Bugzilla.
Any software depending on GConf is partially unsupported at this point.

> 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.

Can you think of another way to implement it?  I figured there wouldn't
be very many of them (like we wouldn't track minor versions of
libraries) so they'd be relatively easy to track.  It seems to me that
we're more or less providing clearer definition for the MIR team as, in
the example above, they should probably be rejecting packages using
GConf on the security maintainability basis but don't really have the
grounds to do it until an issue is found.

		--Ted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120226/16c025f8/attachment.pgp>