Re: EPEL Python 3 for 7?
On Thu, Jan 16, 2014 at 6:28 PM, Toshio Kuratomi a.bad...@gmail.com 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?
On Fri, Jan 17, 2014 at 6:00 AM, Stephen Gallagher sgall...@redhat.comwrote: -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 sgall...@redhat.com 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?
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--mat...@fedoraproject.org ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
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?
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--mat...@fedoraproject.org ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
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?
On Fri, 17 Jan 2014 08:00:58 -0500 Stephen Gallagher sgall...@redhat.com 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 wait until your apps all are able to work with 1.5 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?
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
