LTS-to-LTS Cycle Freezes: Transitions

[Scott Kitterman]

On Saturday, February 25, 2012 09:30:27 PM 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"?

Part of the problem here is that we would need to decide what we mean by 
'support'.  Canonical provides some degree of support for Main, but the rest 
is also supported to some extent by others.

I think it might be better to talk in terms of technology goals or targets.

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

Right, so some of the technologies we'd want to push and other's we'd have to 
wait on.  As an example, in this cycle we've done a lot of work on getting 
Python 3 support in place.  A lot of this was 'just' packaging, but in some 
cases (like Barry Warsaw's work on dbus-python) it's been upstream porting 
work.

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

No, Ubuntu is not strictly an LSB distro (thus the we might or might not care 
about), but there are aspects of LSB that I think we want to support.  BTW, we 
wouldn't have to switch to RPM, we just have to support it and we do.  All the 
tools for RPM based installs are in the archive (although I've never actually 
tried to install one).

Scott K