brainstorming for UDS-N - Package Selection and Defaults

[Matthias Klose]

On 07.10.2010 22:19, Barry Warsaw wrote:
> On Oct 07, 2010, at 03:10 PM, Matthias Klose wrote:
>
>> On 04.10.2010 02:30, Robert Collins wrote:
>>> It would be really nice, as a 'runs unpackaged stuff on the distro'
>>> use case, to support the highest python version on one LTS as a
>>> non-default on the next LTS, consistently.
>>
>> No. why ship 2.6 with the next LTS? Why keep ~20MB on each CD which is not
>> used?  If this is needed for developers, then you could provide something
>> like this in a PPA, which is continuously updated.
>
> I think the reason to have overlap in Python versions between LTS releases is
> for the benefit of end users who have applications that are not in our
> archive.  What I mean is that, yes, we can theoretically fix all the
> compatibility problems for packages in main and universe, but we can do
> nothing about third party applications and libraries that are not in our
> archives.  These may be applications that our users have built or bought, have
> installed and running on the current production Lucid machines.
>
> We could support Python 2.6 in a PPA, but I actually think that will be much
> more work for us.  It has the potential for containing every package in main
> and universe.  Imagine Important Corporation X has a mission critical Python
> application that is not yet ported to Python 2.7.  Their choices are
>
> * Don't upgrade to the next LTS
> * Request Python 2.6 compatible builds for dependencies in the official PPA
> * Expend the resources to port their application to 2.7
> * Forget packaging and build everything themselves
>
> As an end user, none of those would be very appealing.
>
> As a policy, I do think it makes sense for us to have one Python version
> overlap between LTS releases.

Are there concrete examples of these applications for end users (no, I wouldn't 
count Launchpad to to it ;).

20MB are 2% of the CD space, and I suppose an end user would care more about 
shipping something useful like a language pack, another application, but not a 
bunch of unused python modules.

> New Python releases come out approximately every 18 months.  New LTS releases
> come out usually every two years.  I'd be surprised if we ever get into a
> situation where we'd jump a Python release (though the migration to Python 3
> will make things interesting).

Shipping an older non-default in an LTS means to support this one for another 
five years. that should be the exception, not the policy.

No, there won't be a migration to python3 which is comparable to the python2.x 
migrations. We'll have two separate stacks, and the python2 stack will remain 
for a while.  The "migration" will be the question when to use which stack for 
the CDs. having both stacks on the CDs is not an option.

>>> As it is users have to migrate *both* the platform and the
>>> python-version of their code simultaneously, and this tends to be
>>> tricky.
>>
>> I doubt that *users* care. More, this is the default behaviour for
>> almost any shared library, there not something special about it.  But
>> if you are supportive to add 3.2 to lucid, sure 3.2 will be supported
>> in the next LTS. I do not intend to have four python version in the
>> archive until the next release.
>
> 3.2 final is scheduled for January 2011.  The next LTS will probably be April
> 2012.  It's unlikely 3.3 will be released by then.  We have Python 3.1 in
> Lucid, so this would mean supporting 3.1 and 3.2 in 12.04.  So that would mean
> 4 versions of Python until 12.04.  OTOH, I'm not convinced we should have the
> same policy for Python 3 as we do for Python 2, yet.

again, no. I don't want to see 3.1 in 12.04, and I think nobody will care. 
There are just too few modules supported in lucid.  It might be easier to add 
3.2 to lucid however.

   Matthias