LTS-to-LTS Cycle Freezes: Transitions

[Ted Gould]

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"?

> > Regardless of whether it's a Canonical thing or not, I think it's a good
> > way to express a general transition away from a particular technology
> > without just flat removing it without any notice at a particular point.
> > But, if that's the only sticking point, I'll be pretty thrilled :-)
> 
> I like the idea of having a general roadmap of where we're going, but in many 
> cases we have to follow upstreams and it's not like we have a great deal of 
> control.
> 
> Kubuntu will use Qt5 when KDE ships a Qt5 based version, so it's on their 
> timeline, not ours.  Similarly Python 3.  While we can port distro specific 
> code to Python 3 (and I think it's an excellent idea), we can only go so far 
> in porting external packages before the maintenance burden gets to be too 
> much.

Sure, of course, we would be relying on upstreams to do the
implementation.  What we'd be defining is what technologies we're
willing to maintain and what we believe constitutes well maintained
software in the OSS ecosystem.  At least enough that we're willing to
put effort into helping it work in Ubuntu.  Of course any upstream is
able to use "My Apps" or a PPA, but we're defining what goes into the
archive.

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.  It seems unlikely that something like KDE would fall into it
as long as we make reasonable goals.

> We also have to deal with issues like LSB requirements (which we may or may 
> not decide we care about) when determining when to get rid of stuff (for 
> example the current LSG release still requires Qt3 even though it's been dead 
> upstream for years).

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

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.

		--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/20120225/0c9d6941/attachment.pgp>