Re: EPEL Python 3 for 7?

[Bohuslav Kabrda]

- Original Message -
> On 01/15/2014 04:26 PM, Orion Poplawski wrote:
> > On 01/15/2014 12:16 AM, Bohuslav Kabrda wrote:
> >> --
> >>
> >>
> >>
> >>
> >> On 14 January 2014 09:57, Orion Poplawski  >> > wrote:
> >>
> >> It seems like it would be nice to have python 3 in EPEL 7.  Anyone
> >> willing to
> >> maintain it there?
> >>
> >> It seems to build fine:
> >> 
> >> http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
> >>
> >>
> >> Well  a couple of other things would be needed beyond just
> >> maintenance:
> >>
> >> 1) Does providing python-3.4 mean that 3.4 will be the only python
> >> every
> >> provided by EPEL?
> >> 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to
> >> be
> >> handled?
> >>
> >> --
> >> Stephen J Smoogen.
> >>
> >>
> >> Well the problem is that once you provide a build for EPEL, you shouldn't
> >> really do major updates [1], so it seems we would be stuck with whatever
> >> we
> >> build for 10+ years. I don't like that very much. We could probably do
> >> python3.4, python3.5 etc, but that'd probably require some modifications
> >> to
> >> dependency generators, etc... I'm not going to stay in anyones way to do
> >> this,
> >> but I won't do it myself.
> >>
> >> Slavek.
> >>
> >> [1]
> >> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_update
> >>
> > 
> > Well, quite frankly, I think anyone expecting 10 years of support for EPEL
> > packages is deluding themselves, some specific packages excepted.  Users of
> > EPEL are probably best served by upgrading to newer versions of EL as soon
> > as
> > practical.
> > 
> > My recommendation would be to ship python 3.4 as a "normal" python3
> > package.
> > The python folks appear to be committed to providing 5 years of security
> > fixes
> > for a release.  This seems to be as long can be reasonably expected of
> > EPEL.
> > 
> > Perhaps as time goes by, it may make sense to package a later python3.X
> > version if people really want to.
> > 
> > 
> 
> This thread appears to have gone off on a lot of tangents.  Getting back to
> the original questions:
> 
> - Shall we build python 3.4 as python3 in EPEL7 when it is released?
> - Anyone willing to maintain it?

As I've noted previously, I won't stand in anyone's way, but I'm not going to 
maintain Python 3 in EPEL 7 myself.

> - I see that 3.4.0 beta 2 is out, time to get it into rawhide at least?

There is a Change proposal for that at [1] and it's a work in progress. The 
thing that is holding me back is handling the ensurepip script. I already have 
an experimental solution, but I have to verify that it works under all possible 
circumstances, first. Also, the Change states that I'll build 3.4 for Rawhide 
only if "reasonably small amount of non-essential packages doesn't build/work 
with Python 3.4", which I haven't had time to test so far.

> Thanks.

Slavek.

[1] https://fedoraproject.org/wiki/Changes/Python_3.4
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Orion Poplawski]

On 01/15/2014 04:26 PM, Orion Poplawski wrote:
> On 01/15/2014 12:16 AM, Bohuslav Kabrda wrote:
>> --
>>
>>
>>
>>
>> On 14 January 2014 09:57, Orion Poplawski > > wrote:
>>
>> It seems like it would be nice to have python 3 in EPEL 7.  Anyone
>> willing to
>> maintain it there?
>>
>> It seems to build fine:
>> 
>> http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
>>
>>
>> Well  a couple of other things would be needed beyond just maintenance:
>>
>> 1) Does providing python-3.4 mean that 3.4 will be the only python every
>> provided by EPEL?
>> 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be
>> handled?
>>
>> -- 
>> Stephen J Smoogen.
>>
>>
>> Well the problem is that once you provide a build for EPEL, you shouldn't
>> really do major updates [1], so it seems we would be stuck with whatever we
>> build for 10+ years. I don't like that very much. We could probably do
>> python3.4, python3.5 etc, but that'd probably require some modifications to
>> dependency generators, etc... I'm not going to stay in anyones way to do 
>> this,
>> but I won't do it myself.
>>
>> Slavek.
>>
>> [1]
>> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_update
>>
> 
> Well, quite frankly, I think anyone expecting 10 years of support for EPEL
> packages is deluding themselves, some specific packages excepted.  Users of
> EPEL are probably best served by upgrading to newer versions of EL as soon as
> practical.
> 
> My recommendation would be to ship python 3.4 as a "normal" python3 package.
> The python folks appear to be committed to providing 5 years of security fixes
> for a release.  This seems to be as long can be reasonably expected of EPEL.
> 
> Perhaps as time goes by, it may make sense to package a later python3.X
> version if people really want to.
> 
> 

This thread appears to have gone off on a lot of tangents.  Getting back to
the original questions:

- Shall we build python 3.4 as python3 in EPEL7 when it is released?
- Anyone willing to maintain it?
- I see that 3.4.0 beta 2 is out, time to get it into rawhide at least?

Thanks.

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

Re: EPEL Python 3 for 7?

[Kevin Fenzi]

On Fri, 17 Jan 2014 08:00:58 -0500
Stephen Gallagher  wrote:

> My thoughts are these (in no particular order).
>  * Treat this branch like Rawhide. All builds targeted at this are
> composed to a repo. Signing is nice, but not mandatory in my opinion.

It's pretty much impossible to sign rawhide style repos. ;) 

>  * When rhel7.1 comes out, there is no automatic movement from
> epel7-pending into the epel branch. We open a merge window where
> packages are allowed to merge from the epel7-pending git branch.
> Merging a major upgrade outside this window is forbidden. At this
> time, any packager that believes their package is ready for prime-time
> may manually perform a merge, build and submission to Bodhi.

ok. How long does the merge window last? Can people push to stable
during this? Or everything stays in testing until the window closes?

> I think we could set a policy of "merge window opens one week after
> official RHEL release and remains open for two/three weeks after
> that". Packages have to go through Bodhi approval for upgrade (perhaps
> we mandate at least one positive karma review on major upgrades?)
> which may take longer than the merge window, but they have to be
> submitted within that time.

This leaves people using enterprise linux rebuilds in a bad place since
they don't have the new release to test with. Only once they have
upgraded would they be able to be sure the packages are good for the
new release. 

This also means that many folks will delay the update on many of their
machines (7.0->7.1) until the window is over and they can update epel
stuff at the same time. Otherwise they have to schedule 2 big updates
(the 7.0->7.1 and the epel merge window closing).

> The majority isn't necessarily as interesting as the popular packages.

Well, it's like anything else... "I don't care about any packages
except this specific ones that I really really care about" :) 

> There are plenty of people out there who want to see new Django,
> Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade
> in EPEL 6 today because they aren't fully backwards-compatible.

Well, Django is a interesting one... whats wrong with the forward
compat packages there? 

Install Django14 

Update to Django15 and do the incompatible update
lather, rinse, repeat. 

I know, the pain there is the packaging... 

> COPRs is really a workaround for (IMHO) a failure of policy in EPEL to
> remain useful as the world moves ahead. It's pretty unrealistic to
> expect volunteer package maintainers to support their packages for the
> same duration that Red Hat supports RHEL (currently ten years for RHEL
> 5 and 6). I think we're discouraging community inclusion if we don't
> offer people a policy that allows them to keep their package closer to
> upstream for reduced maintenance effort.

Well, I think lots of people do find EPEL useful. I know I do. 

It's a balancing act. Lots of different groups want different things. 
Additionally, it's hard to say what most EPEL consumers want because
they aren't very vocal, they just consume. ;) 

What about Toshios ideas of allowing conflicts: 

We add a EPEL specific guideline that allows forward compat packages to
NOT be parallel installable, as long as they conflict with the other
versions of that package. Would that get us to a better place?
That reduces the problems with making parallel installable compat
packages, you simply need to adjust the names and pass review. 

kevin


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

Re: EPEL Python 3 for 7?

[Toshio Kuratomi]

On Fri, Jan 17, 2014 at 01:57:18PM -0500, Matthew Miller wrote:
> On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote:
> > > Packages for Infrastructure and Clouds, I think). I was thinking about 
> > > this
> > > more recently in the context of "things we need for Fedora.next in the
> > > coming year or so". The new repo might target both EL and Fedora and 
> > > provide
> > > alternative versions maintained on, say, a 3-year lifecycle.
> > Yeah -- I think that something like this could be good.  A repo with
> > a 3 year lifecycle may make sense for RHEL more than Fedora as the
> > basesystem we're building on is still active at the end of that period.
> 
> I'm thinking here about SCLs (or possibly other stack/env tech) that might
> target current supported Fedora but have a longer lifecyle of its own (with
> best-effort compatibility for three years).
> 
> I keep coming back to this idea because it's what people ask me for. :)
> 
Ah I see.  I think present thinking around SCLs has revolved around lifetime
for indivudal SCLs but having a repository wide lifetime could be either
better or a useful additional guarantee.

-Toshio


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

Re: EPEL Python 3 for 7?

[Matthew Miller]

On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote:
> > Packages for Infrastructure and Clouds, I think). I was thinking about this
> > more recently in the context of "things we need for Fedora.next in the
> > coming year or so". The new repo might target both EL and Fedora and provide
> > alternative versions maintained on, say, a 3-year lifecycle.
> Yeah -- I think that something like this could be good.  A repo with
> a 3 year lifecycle may make sense for RHEL more than Fedora as the
> basesystem we're building on is still active at the end of that period.

I'm thinking here about SCLs (or possibly other stack/env tech) that might
target current supported Fedora but have a longer lifecyle of its own (with
best-effort compatibility for three years).

I keep coming back to this idea because it's what people ask me for. :)

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

Re: EPEL Python 3 for 7?

[Toshio Kuratomi]

On Fri, Jan 17, 2014 at 10:55:09AM -0500, Matthew Miller wrote:
> On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote:
> > > system.so we've mostly decided that things in the system shouldn't use 
> > > SCLs
> > > to work.  So we still need to solve the problem of newer python 
> > > interpreter
> > > and newer django framework for use with apps that EPEL ships.
> > What about having a separate EPEL repo for SCLs and/or these newest version
> > of things? Like you mentioned before, this takes more work, but if then
> > those that want the stable base can have it and those that want the newest
> > can have it as well.
> 
The problem I'm raising is that SCLs don't solve the problem that sgallagh
is wanting to address by current policy.  He has applications (ReviewBoard)
that need newer versions of a framework (django) in order to run.  For us to
ship reviewboard in EPEL, we'd need to figure out if we want to allow that
and how.  Possible options are:

* ReviewBoard is in its own SCL.  The SCL deps on the appropriate django SCL.
* ReviewBoard is not in an SCL and we allow mainstream packages to dep on
  SCLs.  We need to figure out guidance on how a package can enable an scl
  for its own use as well.

Either of these may exacerbate the problem of an enabled scl polluting other
applications (especially hard if we get into invoking other processes from
that application... env variables like LD_LIBRRY_PATH will probably get
passed onto the invoked process).

> Or possibly an additional sub-project separate from EPEL. The idea has been
> kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra
> Packages for Infrastructure and Clouds, I think). I was thinking about this
> more recently in the context of "things we need for Fedora.next in the
> coming year or so". The new repo might target both EL and Fedora and provide
> alternative versions maintained on, say, a 3-year lifecycle.
> 
Yeah -- I think that something like this could be good.  A repo with
a 3 year lifecycle may make sense for RHEL more than Fedora as the
basesystem we're building on is still active at the end of that period.



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

Re: EPEL Python 3 for 7?

[Matthew Miller]

On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote:
> > system.so we've mostly decided that things in the system shouldn't use SCLs
> > to work.  So we still need to solve the problem of newer python interpreter
> > and newer django framework for use with apps that EPEL ships.
> What about having a separate EPEL repo for SCLs and/or these newest version
> of things? Like you mentioned before, this takes more work, but if then
> those that want the stable base can have it and those that want the newest
> can have it as well.

Or possibly an additional sub-project separate from EPEL. The idea has been
kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra
Packages for Infrastructure and Clouds, I think). I was thinking about this
more recently in the context of "things we need for Fedora.next in the
coming year or so". The new repo might target both EL and Fedora and provide
alternative versions maintained on, say, a 3-year lifecycle.


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

Re: EPEL Python 3 for 7?

[Dave Johansen]

On Fri, Jan 17, 2014 at 6:00 AM, Stephen Gallagher wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/16/2014 10:14 AM, Kevin Fenzi wrote:
> > On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher
> >  wrote:
> >
> >> Perhaps this would be a good time to reopen the conversation of
> >> minor-release policy changes?
> >
> > Sure.
> >
> >> RHEL releases approximately every six months with a minor
> >> release. It seems fair to allow major EPEL upgrades to occur in
> >> sync with those releases as well.
> >>
> >> So my suggestion would be that EPEL should have two branches for
> >> EPEL 7: the epel7 branch and the epel7-pending branch. The idea
> >> of this second branch would be sort of an EPEL Rawhide, where
> >> major upgrades can be staged. Then, when RHEL releases a minor
> >> update (such as RHEL 7.1), we have a (one-month?) integration
> >> period where we ensure that packages in epel7-pending work on the
> >> newest minor release and then they are merged back to epel7. If
> >> they miss this merge window, they have to wait until the next
> >> minor release.
> >>
> >> This allows us a regular, planned ability to move to newer EPEL
> >> packages, without destabilizing EPEL in general.
> >
> > ok, issues/thoughts:
> >
> > * Another branch is a fair bit more work rel-eng and infra wise.
> > Would they be completely seperate? How do we merge them at a update
> > point?
> >
> > ie, say I have foo. I have 1.0 in epel7 and push 1.2 to
> > epel7-pending. Does the epel7-pending one use bodhi? Does it get
> > signed and composed and push to a repo somewhere? now, say rhel7.1
> > comes out. How do we reconcile the two branches/trees/composes?
> >
>
> My thoughts are these (in no particular order).
>  * Treat this branch like Rawhide. All builds targeted at this are
> composed to a repo. Signing is nice, but not mandatory in my opinion.
>  * When rhel7.1 comes out, there is no automatic movement from
> epel7-pending into the epel branch. We open a merge window where
> packages are allowed to merge from the epel7-pending git branch.
> Merging a major upgrade outside this window is forbidden. At this
> time, any packager that believes their package is ready for prime-time
> may manually perform a merge, build and submission to Bodhi.
>
>
> > * The change point seems like it would be kinda fluid, which would
> > not be great expectation wise. Ie, say rhel7.1 comes out. How long
> > after that do we wait to push the changes? We can't really do it
> > the same time, as we won't know for sure what that will be. We
> > could do it as soon as it's public, but then enterprise rebuilds
> > aren't ready yet. We could wait for CentOS, but then do we wait for
> > SL? OEL? Do we tell users "it can happen some random time after a
> > minor release, please pay attention"?
> >
>
> I think we could set a policy of "merge window opens one week after
> official RHEL release and remains open for two/three weeks after
> that". Packages have to go through Bodhi approval for upgrade (perhaps
> we mandate at least one positive karma review on major upgrades?)
> which may take longer than the merge window, but they have to be
> submitted within that time.
>
>
> > * The majority of epel packages I think don't care about this.
> > It's only a subset. Perhaps we could do something with them? Move
> > them to coprs, get them in as CentOS variants, something?
> >
>
> The majority isn't necessarily as interesting as the popular packages.
> There are plenty of people out there who want to see new Django,
> Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade
> in EPEL 6 today because they aren't fully backwards-compatible.
>
> COPRs is really a workaround for (IMHO) a failure of policy in EPEL to
> remain useful as the world moves ahead. It's pretty unrealistic to
> expect volunteer package maintainers to support their packages for the
> same duration that Red Hat supports RHEL (currently ten years for RHEL
> 5 and 6). I think we're discouraging community inclusion if we don't
> offer people a policy that allows them to keep their package closer to
> upstream for reduced maintenance effort.
>

Yes, this makes the experience better for maintainers, but makes the
experience worse for users and developers of existing tools/infrastructure.
All the RHEL users I know choose it because they want a stable platform
that isn't changing every 6 months to a year. Like Toshio mentioned before,
existing projects want what's there to stay there and new projects want the
latest and greatest. The EL mentality is "stable and predictable" and the
Fedora mentality is "latest and greatest", so I think that both options are
there for those that want them and I don't think that changing EL to be
more Fedora like is a good thing.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Dave Johansen]

On Thu, Jan 16, 2014 at 6:28 PM, Toshio Kuratomi  wrote:

> On Thu, Jan 16, 2014 at 04:47:04PM -0800, Dave Peterson wrote:
> >
> > Wouldn't this be a perfect use case for Software Collections?
> >
> >
> http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/
> > Software_Collections_Guide/index.html
> >
> I was considering this earlier and I'm a bit conflicted about that.
>  There's
> several problems with this.  The most obvious is that SCLs are rather
> coarse
> grained and we want to solve this for both the coarse grained stuff like
> (python interpreter) and fine grained things (like upgrading a single
> library)
>
> The second problem is that we don't just want these things for users to
> use.  We also
> want them for our own use.  But SCLs are meant to be isolated from the
> system.so we've mostly decided that things in the system shouldn't use SCLs
> to work.  So we still need to solve the problem of newer python interpreter
> and newer django framework for use with apps that EPEL ships.
>

What about having a separate EPEL repo for SCLs and/or these newest version
of things? Like you mentioned before, this takes more work, but if then
those that want the stable base can have it and those that want the newest
can have it as well.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2014 10:14 AM, Kevin Fenzi wrote:
> On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher
>  wrote:
> 
>> Perhaps this would be a good time to reopen the conversation of 
>> minor-release policy changes?
> 
> Sure.
> 
>> RHEL releases approximately every six months with a minor
>> release. It seems fair to allow major EPEL upgrades to occur in
>> sync with those releases as well.
>> 
>> So my suggestion would be that EPEL should have two branches for
>> EPEL 7: the epel7 branch and the epel7-pending branch. The idea
>> of this second branch would be sort of an EPEL Rawhide, where
>> major upgrades can be staged. Then, when RHEL releases a minor
>> update (such as RHEL 7.1), we have a (one-month?) integration
>> period where we ensure that packages in epel7-pending work on the
>> newest minor release and then they are merged back to epel7. If
>> they miss this merge window, they have to wait until the next
>> minor release.
>> 
>> This allows us a regular, planned ability to move to newer EPEL 
>> packages, without destabilizing EPEL in general.
> 
> ok, issues/thoughts:
> 
> * Another branch is a fair bit more work rel-eng and infra wise.
> Would they be completely seperate? How do we merge them at a update
> point?
> 
> ie, say I have foo. I have 1.0 in epel7 and push 1.2 to
> epel7-pending. Does the epel7-pending one use bodhi? Does it get
> signed and composed and push to a repo somewhere? now, say rhel7.1
> comes out. How do we reconcile the two branches/trees/composes?
> 

My thoughts are these (in no particular order).
 * Treat this branch like Rawhide. All builds targeted at this are
composed to a repo. Signing is nice, but not mandatory in my opinion.
 * When rhel7.1 comes out, there is no automatic movement from
epel7-pending into the epel branch. We open a merge window where
packages are allowed to merge from the epel7-pending git branch.
Merging a major upgrade outside this window is forbidden. At this
time, any packager that believes their package is ready for prime-time
may manually perform a merge, build and submission to Bodhi.


> * The change point seems like it would be kinda fluid, which would
> not be great expectation wise. Ie, say rhel7.1 comes out. How long
> after that do we wait to push the changes? We can't really do it
> the same time, as we won't know for sure what that will be. We
> could do it as soon as it's public, but then enterprise rebuilds
> aren't ready yet. We could wait for CentOS, but then do we wait for
> SL? OEL? Do we tell users "it can happen some random time after a
> minor release, please pay attention"?
> 

I think we could set a policy of "merge window opens one week after
official RHEL release and remains open for two/three weeks after
that". Packages have to go through Bodhi approval for upgrade (perhaps
we mandate at least one positive karma review on major upgrades?)
which may take longer than the merge window, but they have to be
submitted within that time.


> * The majority of epel packages I think don't care about this.
> It's only a subset. Perhaps we could do something with them? Move
> them to coprs, get them in as CentOS variants, something?
> 

The majority isn't necessarily as interesting as the popular packages.
There are plenty of people out there who want to see new Django,
Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade
in EPEL 6 today because they aren't fully backwards-compatible.

COPRs is really a workaround for (IMHO) a failure of policy in EPEL to
remain useful as the world moves ahead. It's pretty unrealistic to
expect volunteer package maintainers to support their packages for the
same duration that Red Hat supports RHEL (currently ten years for RHEL
5 and 6). I think we're discouraging community inclusion if we don't
offer people a policy that allows them to keep their package closer to
upstream for reduced maintenance effort.


>> In order to not make this a willy-nilly breakage every six
>> months, we might want to set some limits (or at least guidelines)
>> on what is or is not allowed to upgrade at the minor release. But
>> I'd be fine with deferring making such decisions until we have a
>> demonstrated need (i.e. fix it only if packages/EPEL is actually
>> breaking).
> 
> Sure, agreed.
> 
> kevin
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLZKYoACgkQeiVVYja6o6N1OQCfdjqz1iSCBa2UuHmNJXgwvLHv
oIwAoIfjRDbLiIreJ9bIIFflNaAg1vY6
=8gY5
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Toshio Kuratomi]

On Thu, Jan 16, 2014 at 04:47:04PM -0800, Dave Peterson wrote:
> 
> Wouldn't this be a perfect use case for Software Collections?
> 
> http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/
> Software_Collections_Guide/index.html
> 
I was considering this earlier and I'm a bit conflicted about that.  There's
several problems with this.  The most obvious is that SCLs are rather coarse
grained and we want to solve this for both the coarse grained stuff like
(python interpreter) and fine grained things (like upgrading a single
library)

The second problem is that we don't just want these things for users to use.  
We also
want them for our own use.  But SCLs are meant to be isolated from the
system.so we've mostly decided that things in the system shouldn't use SCLs
to work.  So we still need to solve the problem of newer python interpreter
and newer django framework for use with apps that EPEL ships.

-Toshio

> -Dave
> 
> 
> 
> 
> On Thu, Jan 16, 2014 at 7:32 AM, Dave Johansen  wrote:
> 
> On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi 
> wrote:
> 
> 
> 
> On Jan 16, 2014 1:08 AM, "Matthias Runge" 
> wrote:
> >
> > On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
> >
> > >
> > > So my suggestion would be that EPEL should have two branches for
> EPEL
> > > 7: the epel7 branch and the epel7-pending branch. The idea of this
> > > second branch would be sort of an EPEL Rawhide, where major
> upgrades
> > > can be staged. Then, when RHEL releases a minor update (such as
> RHEL
> > > 7.1), we have a (one-month?) integration period where we ensure
> that
> > > packages in epel7-pending work on the newest minor release and 
> then
> > > they are merged back to epel7. If they miss this merge window, 
> they
> > > have to wait until the next minor release.
> > >
> > > This allows us a regular, planned ability to move to newer EPEL
> > > packages, without destabilizing EPEL in general.
> > >
> > > In order to not make this a willy-nilly breakage every six months,
> we
> > > might want to set some limits (or at least guidelines) on what is
> or
> > > is not allowed to upgrade at the minor release. But I'd be fine
> with
> > > deferring making such decisions until we have a demonstrated need
> > > (i.e. fix it only if packages/EPEL is actually breaking).
> > Interesting idea, I like that.
> >
> > This would be a place to put e.g django-1.6.
> >
> Although I would favor being able to deprecate one version of a 
> package
> and introduce a newer incompatible version in some manner I have to
> point out here that if we "set some limits" to avoid breaking things
> then those limits would almost certainly cover frameworks and language
> stacks like python and django.
> 
> This is the basic problem that we inevitably face - people who have
> deployed software that relies on the old version inevitably do not 
> want
> a new, incompatible version to appear in the reps that causes them to
> have to do extra porting work.  People who have not yet deployed (or
> written) their software want the latest and greatest version of the
> software so they can build it using features provided by the latest
> version.
> 
> I think there's two classes of upgrade policy that we might implement
> to address this.
> 
> 1) we think we have enough manpower in epel to support more packages. 
> If this is the case then we should be looking at ways to support more
> than one version of packages on the repository.  Ideas here include:
> 
> + parallel versions (what we do today.  Parallel installable Python3.3
> and python3.4 packages are in this vein).
> 
> + multiple versions that have explicit conflicts between them. 
> Conflicts aren't allowed in fedora packages but this could be an epel
> difference.
> 
> 2) we don't feel we have the manpower to support multiple versions.  
> In
> this case we have to decide whether we are more strongly in favor of
> supporting existing deployments or supporting new deployments. 
> Existing deployments is our default now.  Our story for new 
> deployments
> is that we must have parallel installable versions to make that use
> case work.  Sgallagh's proposal turns that around so that we favour 
> new
> deployments' needs more than existing ones.  There are ways to improve
> it for existing deployments - for instance we could create a new
> repository for each of these point releases. Those repositories could
> be open or closed for new packages/updates depending on

Re: EPEL Python 3 for 7?

[Dave Peterson]

Wouldn't this be a perfect use case for Software Collections?

http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/index.html

-Dave




On Thu, Jan 16, 2014 at 7:32 AM, Dave Johansen wrote:

> On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi wrote:
>
>
>> On Jan 16, 2014 1:08 AM, "Matthias Runge" 
>> wrote:
>> >
>> > On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
>> >
>> > >
>> > > So my suggestion would be that EPEL should have two branches for EPEL
>> > > 7: the epel7 branch and the epel7-pending branch. The idea of this
>> > > second branch would be sort of an EPEL Rawhide, where major upgrades
>> > > can be staged. Then, when RHEL releases a minor update (such as RHEL
>> > > 7.1), we have a (one-month?) integration period where we ensure that
>> > > packages in epel7-pending work on the newest minor release and then
>> > > they are merged back to epel7. If they miss this merge window, they
>> > > have to wait until the next minor release.
>> > >
>> > > This allows us a regular, planned ability to move to newer EPEL
>> > > packages, without destabilizing EPEL in general.
>> > >
>> > > In order to not make this a willy-nilly breakage every six months, we
>> > > might want to set some limits (or at least guidelines) on what is or
>> > > is not allowed to upgrade at the minor release. But I'd be fine with
>> > > deferring making such decisions until we have a demonstrated need
>> > > (i.e. fix it only if packages/EPEL is actually breaking).
>> > Interesting idea, I like that.
>> >
>> > This would be a place to put e.g django-1.6.
>> >
>> Although I would favor being able to deprecate one version of a package
>> and introduce a newer incompatible version in some manner I have to point
>> out here that if we "set some limits" to avoid breaking things then those
>> limits would almost certainly cover frameworks and language stacks like
>> python and django.
>>
>> This is the basic problem that we inevitably face - people who have
>> deployed software that relies on the old version inevitably do not want a
>> new, incompatible version to appear in the reps that causes them to have to
>> do extra porting work.  People who have not yet deployed (or written) their
>> software want the latest and greatest version of the software so they can
>> build it using features provided by the latest version.
>>
>> I think there's two classes of upgrade policy that we might implement to
>> address this.
>>
>> 1) we think we have enough manpower in epel to support more packages.  If
>> this is the case then we should be looking at ways to support more than one
>> version of packages on the repository.  Ideas here include:
>>
>> + parallel versions (what we do today.  Parallel installable Python3.3
>> and python3.4 packages are in this vein).
>>
>> + multiple versions that have explicit conflicts between them.  Conflicts
>> aren't allowed in fedora packages but this could be an epel difference.
>>
>> 2) we don't feel we have the manpower to support multiple versions.  In
>> this case we have to decide whether we are more strongly in favor of
>> supporting existing deployments or supporting new deployments.  Existing
>> deployments is our default now.  Our story for new deployments is that we
>> must have parallel installable versions to make that use case work.
>> Sgallagh's proposal turns that around so that we favour new deployments'
>> needs more than existing ones.  There are ways to improve it for existing
>> deployments - for instance we could create a new repository for each of
>> these point releases. Those repositories could be open or closed for new
>> packages/updates depending on how much manpower we think we have to throw
>> at the problem.
>>
>
> My personal vote would be for either the parallel versions of #1 so people
> aren't forced to upgrade or #2 with maintaining the priority for existing
> deployments. EL provides a known/stable base and I think that EPEL should
> maintain that same philosophy for at least the frameworks and language
> stacks.
>
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Dave Johansen]

On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi  wrote:


> On Jan 16, 2014 1:08 AM, "Matthias Runge" 
> wrote:
> >
> > On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
> >
> > >
> > > So my suggestion would be that EPEL should have two branches for EPEL
> > > 7: the epel7 branch and the epel7-pending branch. The idea of this
> > > second branch would be sort of an EPEL Rawhide, where major upgrades
> > > can be staged. Then, when RHEL releases a minor update (such as RHEL
> > > 7.1), we have a (one-month?) integration period where we ensure that
> > > packages in epel7-pending work on the newest minor release and then
> > > they are merged back to epel7. If they miss this merge window, they
> > > have to wait until the next minor release.
> > >
> > > This allows us a regular, planned ability to move to newer EPEL
> > > packages, without destabilizing EPEL in general.
> > >
> > > In order to not make this a willy-nilly breakage every six months, we
> > > might want to set some limits (or at least guidelines) on what is or
> > > is not allowed to upgrade at the minor release. But I'd be fine with
> > > deferring making such decisions until we have a demonstrated need
> > > (i.e. fix it only if packages/EPEL is actually breaking).
> > Interesting idea, I like that.
> >
> > This would be a place to put e.g django-1.6.
> >
> Although I would favor being able to deprecate one version of a package
> and introduce a newer incompatible version in some manner I have to point
> out here that if we "set some limits" to avoid breaking things then those
> limits would almost certainly cover frameworks and language stacks like
> python and django.
>
> This is the basic problem that we inevitably face - people who have
> deployed software that relies on the old version inevitably do not want a
> new, incompatible version to appear in the reps that causes them to have to
> do extra porting work.  People who have not yet deployed (or written) their
> software want the latest and greatest version of the software so they can
> build it using features provided by the latest version.
>
> I think there's two classes of upgrade policy that we might implement to
> address this.
>
> 1) we think we have enough manpower in epel to support more packages.  If
> this is the case then we should be looking at ways to support more than one
> version of packages on the repository.  Ideas here include:
>
> + parallel versions (what we do today.  Parallel installable Python3.3 and
> python3.4 packages are in this vein).
>
> + multiple versions that have explicit conflicts between them.  Conflicts
> aren't allowed in fedora packages but this could be an epel difference.
>
> 2) we don't feel we have the manpower to support multiple versions.  In
> this case we have to decide whether we are more strongly in favor of
> supporting existing deployments or supporting new deployments.  Existing
> deployments is our default now.  Our story for new deployments is that we
> must have parallel installable versions to make that use case work.
> Sgallagh's proposal turns that around so that we favour new deployments'
> needs more than existing ones.  There are ways to improve it for existing
> deployments - for instance we could create a new repository for each of
> these point releases. Those repositories could be open or closed for new
> packages/updates depending on how much manpower we think we have to throw
> at the problem.
>

My personal vote would be for either the parallel versions of #1 so people
aren't forced to upgrade or #2 with maintaining the priority for existing
deployments. EL provides a known/stable base and I think that EPEL should
maintain that same philosophy for at least the frameworks and language
stacks.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Kevin Fenzi]

On Wed, 15 Jan 2014 10:32:18 -0500
Stephen Gallagher  wrote:

> Perhaps this would be a good time to reopen the conversation of
> minor-release policy changes?

Sure. 

> RHEL releases approximately every six months with a minor release. It
> seems fair to allow major EPEL upgrades to occur in sync with those
> releases as well.
> 
> So my suggestion would be that EPEL should have two branches for EPEL
> 7: the epel7 branch and the epel7-pending branch. The idea of this
> second branch would be sort of an EPEL Rawhide, where major upgrades
> can be staged. Then, when RHEL releases a minor update (such as RHEL
> 7.1), we have a (one-month?) integration period where we ensure that
> packages in epel7-pending work on the newest minor release and then
> they are merged back to epel7. If they miss this merge window, they
> have to wait until the next minor release.
> 
> This allows us a regular, planned ability to move to newer EPEL
> packages, without destabilizing EPEL in general.

ok, issues/thoughts: 

* Another branch is a fair bit more work rel-eng and infra wise. Would
  they be completely seperate? How do we merge them at a update point? 

ie, say I have foo. I have 1.0 in epel7 and push 1.2 to epel7-pending. 
Does the epel7-pending one use bodhi?
Does it get signed and composed and push to a repo somewhere?
now, say rhel7.1 comes out. How do we reconcile the two
branches/trees/composes?

* The change point seems like it would be kinda fluid, which would not
  be great expectation wise. Ie, say rhel7.1 comes out. How long after
  that do we wait to push the changes? We can't really do it the same
  time, as we won't know for sure what that will be. We could do it as
  soon as it's public, but then enterprise rebuilds aren't ready yet.
  We could wait for CentOS, but then do we wait for SL? OEL? Do we
  tell users "it can happen some random time after a minor release,
  please pay attention"?

* The majority of epel packages I think don't care about this. It's
  only a subset. Perhaps we could do something with them? Move them to
  coprs, get them in as CentOS variants, something?
 
> In order to not make this a willy-nilly breakage every six months, we
> might want to set some limits (or at least guidelines) on what is or
> is not allowed to upgrade at the minor release. But I'd be fine with
> deferring making such decisions until we have a demonstrated need
> (i.e. fix it only if packages/EPEL is actually breaking).

Sure, agreed. 

kevin


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

Re: EPEL Python 3 for 7?

[Toshio Kuratomi]

On Jan 16, 2014 1:08 AM, "Matthias Runge"  wrote:
>
> On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
>
> >
> > So my suggestion would be that EPEL should have two branches for EPEL
> > 7: the epel7 branch and the epel7-pending branch. The idea of this
> > second branch would be sort of an EPEL Rawhide, where major upgrades
> > can be staged. Then, when RHEL releases a minor update (such as RHEL
> > 7.1), we have a (one-month?) integration period where we ensure that
> > packages in epel7-pending work on the newest minor release and then
> > they are merged back to epel7. If they miss this merge window, they
> > have to wait until the next minor release.
> >
> > This allows us a regular, planned ability to move to newer EPEL
> > packages, without destabilizing EPEL in general.
> >
> > In order to not make this a willy-nilly breakage every six months, we
> > might want to set some limits (or at least guidelines) on what is or
> > is not allowed to upgrade at the minor release. But I'd be fine with
> > deferring making such decisions until we have a demonstrated need
> > (i.e. fix it only if packages/EPEL is actually breaking).
> Interesting idea, I like that.
>
> This would be a place to put e.g django-1.6.
>
Although I would favor being able to deprecate one version of a package and
introduce a newer incompatible version in some manner I have to point out
here that if we "set some limits" to avoid breaking things then those
limits would almost certainly cover frameworks and language stacks like
python and django.

This is the basic problem that we inevitably face - people who have
deployed software that relies on the old version inevitably do not want a
new, incompatible version to appear in the reps that causes them to have to
do extra porting work.  People who have not yet deployed (or written) their
software want the latest and greatest version of the software so they can
build it using features provided by the latest version.

I think there's two classes of upgrade policy that we might implement to
address this.

1) we think we have enough manpower in epel to support more packages.  If
this is the case then we should be looking at ways to support more than one
version of packages on the repository.  Ideas here include:

+ parallel versions (what we do today.  Parallel installable Python3.3 and
python3.4 packages are in this vein).

+ multiple versions that have explicit conflicts between them.  Conflicts
aren't allowed in fedora packages but this could be an epel difference.

2) we don't feel we have the manpower to support multiple versions.  In
this case we have to decide whether we are more strongly in favor of
supporting existing deployments or supporting new deployments.  Existing
deployments is our default now.  Our story for new deployments is that we
must have parallel installable versions to make that use case work.
Sgallagh's proposal turns that around so that we favour new deployments'
needs more than existing ones.  There are ways to improve it for existing
deployments - for instance we could create a new repository for each of
these point releases. Those repositories could be open or closed for new
packages/updates depending on how much manpower we think we have to throw
at the problem.

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

Re: EPEL Python 3 for 7?

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2014 04:08 AM, Matthias Runge wrote:
> On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
> 
>> 
>> So my suggestion would be that EPEL should have two branches for
>> EPEL 7: the epel7 branch and the epel7-pending branch. The idea
>> of this second branch would be sort of an EPEL Rawhide, where
>> major upgrades can be staged. Then, when RHEL releases a minor
>> update (such as RHEL 7.1), we have a (one-month?) integration
>> period where we ensure that packages in epel7-pending work on the
>> newest minor release and then they are merged back to epel7. If
>> they miss this merge window, they have to wait until the next
>> minor release.
>> 
>> This allows us a regular, planned ability to move to newer EPEL 
>> packages, without destabilizing EPEL in general.
>> 
>> In order to not make this a willy-nilly breakage every six
>> months, we might want to set some limits (or at least guidelines)
>> on what is or is not allowed to upgrade at the minor release. But
>> I'd be fine with deferring making such decisions until we have a
>> demonstrated need (i.e. fix it only if packages/EPEL is actually
>> breaking).
> Interesting idea, I like that.
> 
> This would be a place to put e.g django-1.6.
> 
> In general: when allowing package upgrades, there might be manual
> steps required after package upgrade, like starting database
> migrations, tweaking config files to adjust to new syntax, etc. I'm
> not sure, if that is really acceptable.
> 

In the case of Django, my experience has been that this is often
required for even minor updates (see Review Board for examples). My
solution there was to work with upstream to build tools to
automatically manage these upgrades so they are invisible to the
package consumer.


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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLX6BgACgkQeiVVYja6o6PpTACdE0N5WEkjSj2JqPMOLAnwZpBg
5jYAoJGGSZdNCA72YXj7OLeaMygF9dKh
=sGuM
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Matthias Runge]

On 01/15/2014 04:32 PM, Stephen Gallagher wrote:

> 
> So my suggestion would be that EPEL should have two branches for EPEL
> 7: the epel7 branch and the epel7-pending branch. The idea of this
> second branch would be sort of an EPEL Rawhide, where major upgrades
> can be staged. Then, when RHEL releases a minor update (such as RHEL
> 7.1), we have a (one-month?) integration period where we ensure that
> packages in epel7-pending work on the newest minor release and then
> they are merged back to epel7. If they miss this merge window, they
> have to wait until the next minor release.
> 
> This allows us a regular, planned ability to move to newer EPEL
> packages, without destabilizing EPEL in general.
> 
> In order to not make this a willy-nilly breakage every six months, we
> might want to set some limits (or at least guidelines) on what is or
> is not allowed to upgrade at the minor release. But I'd be fine with
> deferring making such decisions until we have a demonstrated need
> (i.e. fix it only if packages/EPEL is actually breaking).
Interesting idea, I like that.

This would be a place to put e.g django-1.6.

In general: when allowing package upgrades, there might be manual steps
required after package upgrade, like starting database migrations,
tweaking config files to adjust to new syntax, etc.
I'm not sure, if that is really acceptable.

Thoughts?

Matthias

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

Re: EPEL Python 3 for 7?

[Orion Poplawski]

On 01/15/2014 12:16 AM, Bohuslav Kabrda wrote:
> --
> 
> 
> 
> 
> On 14 January 2014 09:57, Orion Poplawski  > wrote:
> 
> It seems like it would be nice to have python 3 in EPEL 7.  Anyone
> willing to
> maintain it there?
> 
> It seems to build fine:
> 
> http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
> 
> 
> Well  a couple of other things would be needed beyond just maintenance:
> 
> 1) Does providing python-3.4 mean that 3.4 will be the only python every
> provided by EPEL?
> 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be
> handled?
> 
> -- 
> Stephen J Smoogen.
> 
> 
> Well the problem is that once you provide a build for EPEL, you shouldn't
> really do major updates [1], so it seems we would be stuck with whatever we
> build for 10+ years. I don't like that very much. We could probably do
> python3.4, python3.5 etc, but that'd probably require some modifications to
> dependency generators, etc... I'm not going to stay in anyones way to do this,
> but I won't do it myself.
> 
> Slavek.
> 
> [1]
> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_update
> 

Well, quite frankly, I think anyone expecting 10 years of support for EPEL
packages is deluding themselves, some specific packages excepted.  Users of
EPEL are probably best served by upgrading to newer versions of EL as soon as
practical.

My recommendation would be to ship python 3.4 as a "normal" python3 package.
The python folks appear to be committed to providing 5 years of security fixes
for a release.  This seems to be as long can be reasonably expected of EPEL.

Perhaps as time goes by, it may make sense to package a later python3.X
version if people really want to.


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

Re: EPEL Python 3 for 7?

[Dave Johansen]

On Wed, Jan 15, 2014 at 8:32 AM, Stephen Gallagher wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/15/2014 02:16 AM, Bohuslav Kabrda wrote:
> > 
> >
> >
> >
> >
> >
> > On 14 January 2014 09:57, Orion Poplawski  > > wrote:
> >
> > It seems like it would be nice to have python 3 in EPEL 7. Anyone
> > willing to maintain it there?
> >
> > It seems to build fine:
> > http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
> >
> >
> >
> > Well  a couple of other things would be needed beyond just
> > maintenance:
> >
> > 1) Does providing python-3.4 mean that 3.4 will be the only python
> > every provided by EPEL? 2) If it doesn't then how are upgrades from
> > 3.4 to 3.5 to 3.6 going to be handled?
> >
> > -- Stephen J Smoogen.
> >
> >
> > Well the problem is that once you provide a build for EPEL, you
> > shouldn't really do major updates [1], so it seems we would be
> > stuck with whatever we build for 10+ years. I don't like that very
> > much. We could probably do python3.4, python3.5 etc, but that'd
> > probably require some modifications to dependency generators,
> > etc... I'm not going to stay in anyones way to do this, but I won't
> > do it myself.
> >
>
> Perhaps this would be a good time to reopen the conversation of
> minor-release policy changes?
>
> RHEL releases approximately every six months with a minor release. It
> seems fair to allow major EPEL upgrades to occur in sync with those
> releases as well.
>
> So my suggestion would be that EPEL should have two branches for EPEL
> 7: the epel7 branch and the epel7-pending branch. The idea of this
> second branch would be sort of an EPEL Rawhide, where major upgrades
> can be staged. Then, when RHEL releases a minor update (such as RHEL
> 7.1), we have a (one-month?) integration period where we ensure that
> packages in epel7-pending work on the newest minor release and then
> they are merged back to epel7. If they miss this merge window, they
> have to wait until the next minor release.
>
> This allows us a regular, planned ability to move to newer EPEL
> packages, without destabilizing EPEL in general.
>
> In order to not make this a willy-nilly breakage every six months, we
> might want to set some limits (or at least guidelines) on what is or
> is not allowed to upgrade at the minor release. But I'd be fine with
> deferring making such decisions until we have a demonstrated need
> (i.e. fix it only if packages/EPEL is actually breaking).
>

My understanding is that RHEL minor release can include "major upgrades" to
non-core parts (LibreOffice, Firefox, etc) but that core parts (the kernel,
compiler, python version, etc) don't see "major upgrades". I personally
like that model and think that it provides the stability needed for an
enterprise class system, so I think that those same general guidelines
should be upheld by the EPEL. If you really want/need the latest and
greatest of everything all the time, then I believe that Fedora is probably
a better fit than RHEL.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Bohuslav Kabrda]

- Original Message -

> On 14 January 2014 09:57, Orion Poplawski < or...@cora.nwra.com > wrote:

> > It seems like it would be nice to have python 3 in EPEL 7. Anyone willing
> > to
> 
> > maintain it there?
> 

> > It seems to build fine:
> 
> > http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
> 

> Well a couple of other things would be needed beyond just maintenance:

> 1) Does providing python-3.4 mean that 3.4 will be the only python every
> provided by EPEL?
> 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be
> handled?

> --
> Stephen J Smoogen.

Well the problem is that once you provide a build for EPEL, you shouldn't 
really do major updates [1], so it seems we would be stuck with whatever we 
build for 10+ years. I don't like that very much. We could probably do 
python3.4, python3.5 etc, but that'd probably require some modifications to 
dependency generators, etc... I'm not going to stay in anyones way to do this, 
but I won't do it myself. 

Slavek. 

[1] 
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_update 
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Toshio Kuratomi]

On Tue, Jan 14, 2014 at 09:13:12PM +0100, Jochen Schmitt wrote:
> On Tue, Jan 14, 2014 at 12:35:00PM -0700, Stephen John Smoogen wrote:
> 
> > 1) Does providing python-3.4 mean that 3.4 will be the only python every
> > provided by EPEL?
> 
> On Fedora ew have a python package which points to the 2.7 series and a
> python3 package which points to the 3.3 series of python. I think we
> should take this solution for EPEL because I think that python-2.7.x is
> the standard python version which should not been overriden.
> 
> > 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be
> > handled?
> 
> I think we need a conservative update handling to avoid incompatibilities
> caused due an python update.
> 
We could also take the python2.6 package in EPEL5 as inspiration here and
ship a python3.4.  This would allow us to ship a python3.5, python3.6, etc
set of packages in the future.

-Toshio


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

Re: EPEL Python 3 for 7?

[Jochen Schmitt]

On Tue, Jan 14, 2014 at 12:35:00PM -0700, Stephen John Smoogen wrote:

> 1) Does providing python-3.4 mean that 3.4 will be the only python every
> provided by EPEL?

On Fedora ew have a python package which points to the 2.7 series and a
python3 package which points to the 3.3 series of python. I think we
should take this solution for EPEL because I think that python-2.7.x is
the standard python version which should not been overriden.

> 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be
> handled?

I think we need a conservative update handling to avoid incompatibilities
caused due an python update.

Best Regards:

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

Re: EPEL Python 3 for 7?

[Stephen John Smoogen]

On 14 January 2014 09:57, Orion Poplawski  wrote:

> It seems like it would be nice to have python 3 in EPEL 7.  Anyone willing
> to
> maintain it there?
>
> It seems to build fine:
> http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
>
>
Well  a couple of other things would be needed beyond just maintenance:

1) Does providing python-3.4 mean that 3.4 will be the only python every
provided by EPEL?
2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be
handled?

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

Re: EPEL Python 3 for 7?

[Jochen Schmitt]

On Tue, Jan 14, 2014 at 09:57:18AM -0700, Orion Poplawski wrote:

> It seems like it would be nice to have python 3 in EPEL 7.  Anyone willing to

It may be very helpful to have Python 3 in EPEL-7. I'm planing to provide
the current version of blender on EPEL-7 and this version requires 
Python 3.

Best Regards:

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

EPEL Python 3 for 7?

[Orion Poplawski]

It seems like it would be nice to have python 3 in EPEL 7.  Anyone willing to
maintain it there?

It seems to build fine:
http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/

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