Re: EPEL RFC: Strategy for python3 versions

[Pat Riehecky]

I'm circling back around to this with the recent publication of 
ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/RHSCL/SRPMS/python33-1.1-13.el7.src.rpm 
and friends.


Just looking to ensure everyone who cares about python3 on RHEL7 saw 
these.  Hope this information is useful.


Pat

On 04/30/2014 12:58 PM, Stephen John Smoogen wrote:




On 30 April 2014 08:46, Toshio Kuratomi > wrote:


On Tue, Apr 29, 2014 at 07:22:40PM -0600, Orion Poplawski wrote:
>
> Finally:
>python34-3.4

This has precedent.


The main reason I chose this when doing the mediawiki packages was to 
avoid parsing problems due to the fact that people like to do ls -1 
and then awk/cut out per the first - or . as the package name. I won't 
say that their approach is good but it was the most common one I ran 
into when looking at doing mediawiki117 or mediawiki1.17
(the other solution was an rpm aware ls like program.. just what 
everyone needs to add to ls .deb/.rpm/xxx parsing :).)



> or python3.4-3.4

When I create new compat packages, I like to put dots in the
version so
this works for me as well.

> or python-3.4-3.4

I dislike dashes in that position as it makes it hard to read.


I agree. It makes it very hard to see if I am looking at



--
Stephen J Smoogen.



___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel



--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RFC: Strategy for python3 versions

[Orion Poplawski]

On 04/30/2014 07:51 AM, Pat Riehecky wrote:
> I wonder if the softwarecollections.org repos might be a better choice
> for this.  All the userspace tools already exist in 5, 6 and 7.
> 
> Pat
> 

I think EL7 deserves to have a system integrated python3 version.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RFC: Strategy for python3 versions

[Stephen John Smoogen]

On 30 April 2014 08:46, Toshio Kuratomi  wrote:

> On Tue, Apr 29, 2014 at 07:22:40PM -0600, Orion Poplawski wrote:
> >
> > Finally:
> >python34-3.4
>
> This has precedent.
>
>
The main reason I chose this when doing the mediawiki packages was to avoid
parsing problems due to the fact that people like to do ls -1 and then
awk/cut out per the first - or . as the package name. I won't say that
their approach is good but it was the most common one I ran into when
looking at doing mediawiki117 or mediawiki1.17

(the other solution was an rpm aware ls like program.. just what everyone
needs to add to ls .deb/.rpm/xxx parsing :).)


> or python3.4-3.4
>
> When I create new compat packages, I like to put dots in the version so
> this works for me as well.
>
> > or python-3.4-3.4
>
> I dislike dashes in that position as it makes it hard to read.
>
>
I agree. It makes it very hard to see if I am looking at




-- 
Stephen J Smoogen.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RFC: Strategy for python3 versions

[Stephen John Smoogen]

On 30 April 2014 07:51, Pat Riehecky  wrote:

> I wonder if the softwarecollections.org repos might be a better choice
> for this.  All the userspace tools already exist in 5, 6 and 7.
>
> Pat
>
>
I am thinking that softwarecollections and EPEL may have competing
solutions to the same problems because of the different mechanisms and
problems each are solving.

-- 
Stephen J Smoogen.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RFC: Strategy for python3 versions

[Toshio Kuratomi]

On Tue, Apr 29, 2014 at 07:22:40PM -0600, Orion Poplawski wrote:
> 
> So, I want to be explicit as to how we handle python3 modules in EPEL.
>  Originally I was hoping we could simply have python3.4 provide
> python3 and maintainers could branch their current Fedora python
> modules for epel7 and build as is resulting in python3-module packages
> as in Fedora.
> 
> However, I don't see how we transition easily to the next python3
> release.  I suppose we could do a side tag and rebuild everything then
> have a flag day release.  Does this seem workable (I don't think so)?
> 
I agree, this doesn't seem workable.

> If we're going to require having python34-module packages are we going
> to require new reviews, or can we simply have people name them with
> %package -n python34-module in the epel7 branch?  Would we have people
> maintain multiple versions at a time in a package?  This seems like
> the workable version.  I'm afraid that requiring new review all the
> time will be a serious impediment.
> 
> We'll have %{__python34} etc macros then too.
> 
I hadn't thought about doing things that way but it sounds pretty
attractive.  There are two things that I'm not sure about:

* How do we handle updating the version of a module between python3.N and
  python3.N+1?
  - Perhaps we violate the 1 upstream tarball per-package rule and have one
tarball for python-3.N and a second tarball for python-3.N+1?  I think
doing this would have the same drawbacks as we normally think of for
this case: we'll have to make updates to only one of the tarballs and
that will cause new binary rpms to be created for both of the
subpackages.  So users will have to download packages with no changes.
I think we need to figure out a better solution to this problem.
* How does this interact with Fedora and RHEL/EPEL python modules?
  - We probably don't want to share spec files with the main Fedora python
modules (those will build a single python2 and a single python3 module
from a single tarball so they're very different) or the RHEL python
modules (those will build a single python2 module from a single
tarball).
  - So we probably need a different package namespace.  Since RHEL6/7
doesn't have python3 we could use python3-foo for srpms and create
python3.N-foo subpackages for the binary rpms.  Do we need to worry
about this clashing with packages in Fedora space at all?
+ We wouldn't want Fedora bugzilla to get these package names: maybe we
  have to talk to scm admins about creating packages with no rawhide
  branches [to prevent the pkgdb-bugzilla sync scripts from creating
  a bugzilla entry for them in Fedora]
+ Sometimes upstreams produce a python3 module as a separate tarball
  from the python2 version.  In those cases, Fedora would have
  a separate python3-foo srpm package since it would follow the
  one-tarball-per-package "rule".  We could simply re-use the srpm
  package name without re-using the spec file.  EPEL is probably
  different enough from Fedora that this isn't a problem.

If the problem is re-review (and not maintaining multiple packages) an
alternative might be to short-circuit the review process for these packages.
We can specify in EPEL guidelines that these packages can be reviewed for
differences from the previous EPEL module version rather than a full review.
This is somewhat similar to the package rename case in Fedora which hasn't
been a major bottleneck there but it isn't a problem on the same scale as
we're talking about here.  I think if we could solve the above issues,
a single package would make more sense.

> 
> I like the plan of supporting 2 versions at a time.  I'm willing to
> defer deciding on what the next version should be till later.  Perhaps
> 3.5 won't be all that compelling and we'll want to wait for 3.6.
> 
> Finally:
>python34-3.4

This has precedent.

> or python3.4-3.4

When I create new compat packages, I like to put dots in the version so
this works for me as well.

> or python-3.4-3.4

I dislike dashes in that position as it makes it hard to read.

> or python3-3.4-3.4?

I still dislike dashes but I can see how this would make logical sense if
we name module srpm packages python3-foo and module binary rpm packages as
python3-3.4-foo.  If we name the modules packages python3-foo.src.rpm and
python3.4-foo.noarch.rpm, though, then I'd rather use one of the dash-less
versions above.

> Keep provides python(abi) = 3.4?
> 
I think so.  This is what the python3 package in Fedora does and what the
python26 package in EPEL5 does.  It hasn't caused problems in those places.
I think that it means what we intend to say.

-Toshio


pgpo1wI4A2WLP.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RFC: Strategy for python3 versions

[Orion Poplawski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/29/2014 05:54 PM, Toshio Kuratomi wrote:
> Hi guys,
> 
> Orion has submitted a python34 package for EPEL and I'm going to
> review them soon if no one beats me to it.  In parallel with
> getting that approved I'd like to ask about the general strategy
> we'd like to take with maintaining python3 in EPEL.
> 
> Python3 is an evolving language.  New 3.N releases bring new
> features, bugfixes, and both backwards compatibility breaking and
> backwards compatibility enhancing changes (For instance, 3.3
> brought the ability to mark regular text strings with the "u"
> prefix to match with python2.x.  3.5 will bring back formatting
> methods for byte strings.)

...

> I'd like to propose that we attempt to maintain 2 python3 releases
> at any one time.  We'll create python3.4 now.  When python3.5 comes
> out in 18 months (less since python3.4 has been out for several
> months), we'll package that in addition.  When python3.6 comes out
> (3 years), we'll package that and retire python3.4.
> 
> Pluses: * This gives users some time to verify that their homegrown
> applications continue to work with the newer python3 package that
> we produce before the old one goes EOL. * This means that we're
> only working on 3 versions of python3 at a time (the two we expect
> users to use and the next version that we're tracking as upstream
> works on finishing it). * This gives us a chance to update
> frameworks, libraries, and other stacks of software built on top of
> python3 at the same time as we create the new interpreter package.
> So you could get python3.4 with Django-1.6.x  and you could get
> python3.5 with Django-1.8.x
> 
> Negatives: * Users will have to reverify and port apps written
> against python3 to the new interpreter version sometime in the 3
> year lifespan of the python3 package they originally wrote it
> against. * Package maintainers who are creating packages that run
> on python3 will need to submit new packages for python3.4,
> python3.5, etc. * Users may have to port to both new versions of
> python3 and to new versions of some libraries they depend on
> (because we took the opportunity to update those libraries for the
> new python3 interpreter stack).

So, I want to be explicit as to how we handle python3 modules in EPEL.
 Originally I was hoping we could simply have python3.4 provide
python3 and maintainers could branch their current Fedora python
modules for epel7 and build as is resulting in python3-module packages
as in Fedora.

However, I don't see how we transition easily to the next python3
release.  I suppose we could do a side tag and rebuild everything then
have a flag day release.  Does this seem workable (I don't think so)?

If we're going to require having python34-module packages are we going
to require new reviews, or can we simply have people name them with
%package -n python34-module in the epel7 branch?  Would we have people
maintain multiple versions at a time in a package?  This seems like
the workable version.  I'm afraid that requiring new review all the
time will be a serious impediment.

We'll have %{__python34} etc macros then too.

> Alternatives: * Never retire the python3 packages.  This leaves us
> trying to support the release once upstream stops support.  Since
> new python3 releases are in demand, we'd probably end up trying to
> maintain all of the python3 releases that came out between when
> RHEL-N was released and when RHEL-N+1 releases (because maintainer
> focus usually shifts to building packages for RHEL-N+1 then). *
> Retire the python3 packages when upstream stops support.  This
> defers the pain for users (They can use a python3.N version for
> about 5 years instead of about 3 years).  However, it means that
> we're maintaining 4-5 versions of python3 at a time instead of 2-3
> 
> 
> What do people think?  Is this something we can do within the
> policies of EPEL?  Does it make sense to go forward with this?  Is
> it better to go with one of the alternatives?

I like the plan of supporting 2 versions at a time.  I'm willing to
defer deciding on what the next version should be till later.  Perhaps
3.5 won't be all that compelling and we'll want to wait for 3.6.

Finally:
   python34-3.4
or python3.4-3.4
or python-3.4-3.4
or python3-3.4-3.4?

Keep provides python(abi) = 3.4?

- -- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNgUFwACgkQORnzrtFC2/ujzQCguem5bziFQQZzn1WfLPZaPbuy
adMAoMOmF2Al81HWqxCFGYJgBr5UZcjZ
=OMyV
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/list

Re: EPEL RFC: Strategy for python3 versions

[Kevin Fenzi]

On Tue, 29 Apr 2014 16:54:31 -0700
Toshio Kuratomi  wrote:

...snip...

> What do people think?  Is this something we can do within the
> policies of EPEL?  Does it make sense to go forward with this?  Is it
> better to go with one of the alternatives?
...snip...

I like the plan. I'm happy to help co-maintain/package monkey versions. 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL RFC: Strategy for python3 versions

[Toshio Kuratomi]

Hi guys,

Orion has submitted a python34 package for EPEL and I'm going to review them
soon if no one beats me to it.  In parallel with getting that approved I'd
like to ask about the general strategy we'd like to take with maintaining
python3 in EPEL.

Python3 is an evolving language.  New 3.N releases bring new features,
bugfixes, and both backwards compatibility breaking and backwards
compatibility enhancing changes (For instance, 3.3 brought the ability to
mark regular text strings with the "u" prefix to match with python2.x.  3.5
will bring back formatting methods for byte strings.)

Currently, there are a good many python libraries that work with both
python2 and python3 but few libraries and few applications that are
python3-only.

Upstream, python3 releases generally see 18 months of bugfix updates and
5 years of security fixes[1]_.

As Orion has pointed out, it would be hard for us to maintain a python3
release past upstream's EOL date as there's a lot of code in a python3
package (Not to mention the stack of packages that we'll build on top of
it.)

In addition, I am a little worried about the amount of time we may end up
having to devote to keeping multiple python3.N packages (and stacks of
packages for them) alive if we only retire old python3 releases when
upstream ceases to provide support for them (back of the envelope
calculations are that if we don't skip any python3.N releases, we'd be
attempting to maintain 4-5 python3 releases before the first of those EOL's
upstream).

I'd like to propose that we attempt to maintain 2 python3 releases at any
one time.  We'll create python3.4 now.  When python3.5 comes out in 18
months (less since python3.4 has been out for several months), we'll
package that in addition.  When python3.6 comes out (3 years), we'll package
that and retire python3.4.

Pluses:
* This gives users some time to verify that their homegrown applications
  continue to work with the newer python3 package that we produce before the
  old one goes EOL.
* This means that we're only working on 3 versions of python3 at a time (the
  two we expect users to use and the next version that we're tracking as
  upstream works on finishing it).
* This gives us a chance to update frameworks, libraries, and other stacks
  of software built on top of python3 at the same time as we create the new
  interpreter package.  So you could get python3.4 with Django-1.6.x  and
  you could get python3.5 with Django-1.8.x

Negatives:
* Users will have to reverify and port apps written against python3 to the
  new interpreter version sometime in the 3 year lifespan of the python3
  package they originally wrote it against.
* Package maintainers who are creating packages that run on python3 will
  need to submit new packages for python3.4, python3.5, etc.
* Users may have to port to both new versions of python3 and to new versions
  of some libraries they depend on (because we took the opportunity to
  update those libraries for the new python3 interpreter stack).

Precedents:
* With mediawiki, we now ship versioned packages and retire the old versions
  when upstream stops shipping updates.  The stacks of packages built on top
  of mediawiki have to be produced for each mediawiki version.

Alternatives:
* Never retire the python3 packages.  This leaves us trying to support the
  release once upstream stops support.  Since new python3 releases are in
  demand, we'd probably end up trying to maintain all of the python3
  releases that came out between when RHEL-N was released and when
  RHEL-N+1 releases (because maintainer focus usually shifts to building
  packages for RHEL-N+1 then).
* Retire the python3 packages when upstream stops support.  This defers the
  pain for users (They can use a python3.N version for about 5 years instead
  of about 3 years).  However, it means that we're maintaining 4-5 versions
  of python3 at a time instead of 2-3 

What do people think?  Is this something we can do within the policies of
EPEL?  Does it make sense to go forward with this?  Is it better to go with
one of the alternatives?

.. [1]_: Previous versions of python3 have a lifespan defined in their PEP.  For
  instance, this one for python3.3:
  http://legacy.python.org/dev/peps/pep-0398/#lifespan

  The lifespan for the previous versions are the same:
  * bugfix updates for python3.N approximately every 4-6 months for
approximately 18 months.
  * After the release of python3.N+1, a final bugfix of python3.N is released.
  * After that, security updates (source only) will be released until 5 years
after the initial release of 3.N.

  3.4 doesn't have this lifespan section but that's probably an oversight (I
  can ask Larry Hastings to clarify that if need be).

-Toshio


pgpD0KdHyh6Gn.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel