7:23 p.m.
Hey EPEL people.
We got a request to branch Python 3.7 foe EPEL 7:
https://bugzilla.redhat.com/show_bug.cgi?id=1781940
Are there volunteers to make that effort? And if so, should this be done in EPEL
8 first? And what about Python 3.8 in EPEL 7?
So many questions. So little time.
That said. If somebody want this, we (Python Maint) can help coordinate, but we
don't have the manpower to really maintain various Python versions in EPEL for
next X years.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:01 a.m.
On Tue, 10 Dec 2019 at 20:24, Miro Hrončok <mhroncok(a)redhat.com> wrote:
Hey EPEL people.
We got a request to branch Python 3.7 foe EPEL 7:
https://bugzilla.redhat.com/show_bug.cgi?id=1781940
Are there volunteers to make that effort? And if so, should this be done in EPEL
8 first? And what about Python 3.8 in EPEL 7?
So many questions. So little time.
That said. If somebody want this, we (Python Maint) can help coordinate, but we
don't have the manpower to really maintain various Python versions in EPEL for
next X years.
Honestly after all the work and pain it got to get python36 in
EPEL7... I would prefer not to try that again. I think maintaining the
version that is the base in RHEL-8 is going to be more than enough
headaches and trying to keep up with the python of the year is not
productive. I think that any volunteers should first make the versions
of python37/38 in COPR and see if they have the volunteers and time to
maintain it there.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
--
Stephen J Smoogen.
10:44 a.m.
On 11. 12. 19 17:01, Stephen John Smoogen wrote:
On Tue, 10 Dec 2019 at 20:24, Miro Hrončok
<mhroncok(a)redhat.com> wrote:
>
> Hey EPEL people.
>
> We got a request to branch Python 3.7 foe EPEL 7:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1781940
>
> Are there volunteers to make that effort? And if so, should this be done in EPEL
> 8 first? And what about Python 3.8 in EPEL 7?
>
> So many questions. So little time.
>
> That said. If somebody want this, we (Python Maint) can help coordinate, but we
> don't have the manpower to really maintain various Python versions in EPEL for
> next X years.
>
Honestly after all the work and pain it got to get python36 in
EPEL7... I would prefer not to try that again.
Note that there is a big difference between maintaining a stack of various
python37-foo packages and maintaining the interpreter only.
I think maintaining the
version that is the base in RHEL-8 is going to be more than enough
headaches and trying to keep up with the python of the year is not
productive. I think that any volunteers should first make the versions
of python37/38 in COPR and see if they have the volunteers and time to
maintain it there.
That is true.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
11:50 a.m.
On Wed, 11 Dec 2019 at 11:44, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 11. 12. 19 17:01, Stephen John Smoogen wrote:
> On Tue, 10 Dec 2019 at 20:24, Miro Hrončok <mhroncok(a)redhat.com> wrote:
>>
>> Hey EPEL people.
>>
>> We got a request to branch Python 3.7 foe EPEL 7:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1781940
>>
>> Are there volunteers to make that effort? And if so, should this be done in
EPEL
>> 8 first? And what about Python 3.8 in EPEL 7?
>>
>> So many questions. So little time.
>>
>> That said. If somebody want this, we (Python Maint) can help coordinate, but we
>> don't have the manpower to really maintain various Python versions in EPEL
for
>> next X years.
>>
>
> Honestly after all the work and pain it got to get python36 in
> EPEL7... I would prefer not to try that again.
Note that there is a big difference between maintaining a stack of various
python37-foo packages and maintaining the interpreter only.
The issue is that most 'users' of the language do not see a difference
between the 2. When they say python3x they mean
python3x+whatever-bits-i-needed. So as soon as you put in the
interpreter.. then comes the 'why isn't python37-x there? etc etc'
> I think maintaining the
> version that is the base in RHEL-8 is going to be more than enough
> headaches and trying to keep up with the python of the year is not
> productive. I think that any volunteers should first make the versions
> of python37/38 in COPR and see if they have the volunteers and time to
> maintain it there.
That is true.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
--
Stephen J Smoogen.
4:23 p.m.
On Dec 11, 2019, at 12:50, Stephen John Smoogen <smooge(a)gmail.com> wrote:
The issue is that most 'users' of the language do not see a
difference
between the 2. When they say python3x they mean
python3x+whatever-bits-i-needed. So as soon as you put in the
interpreter.. then comes the 'why isn't python37-x there? etc etc'
IIRC, that is exactly what happened with the 3.4 => 3.6 transition. What made that
particularly painful for me was that the 3.4 versions of many of the dependent bits
suddenly went away, to be *replaced* (rather than augmented) by 3.6 ones. This caused
major disruption in a number of projects that I maintain that had formal dependencies on
the 3.4 bits.
Will this same thing happen to the 3.6 bits if we add 3.7? If so, then I would strongly
oppose making the addition. Having packages spontaneously disappear seems to contradict
the whole point of having an ‘Enterprise’ distro.
Cheers!
|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|---------------------------------------------------------------------|
| A room without books is like a body without a soul. |
| |
| -- Cicero |
|---------------------------------------------------------------------|
4:33 p.m.
On Wed, 11 Dec 2019 at 17:23, Fred Gleason <fredg(a)paravelsystems.com> wrote:
On Dec 11, 2019, at 12:50, Stephen John Smoogen <smooge(a)gmail.com> wrote:
The issue is that most 'users' of the language do not see a difference
between the 2. When they say python3x they mean
python3x+whatever-bits-i-needed. So as soon as you put in the
interpreter.. then comes the 'why isn't python37-x there? etc etc'
IIRC, that is exactly what happened with the 3.4 => 3.6 transition. What made that
particularly painful for me was that the 3.4 versions of many of the dependent bits
suddenly went away, to be *replaced* (rather than augmented) by 3.6 ones. This caused
major disruption in a number of projects that I maintain that had formal dependencies on
the 3.4 bits.
Will this same thing happen to the 3.6 bits if we add 3.7? If so, then I would strongly
oppose making the addition. Having packages spontaneously disappear seems to contradict
the whole point of having an ‘Enterprise’ distro.
I want to correct one thing: EPEL is not an Enterprise repository. It
is a nearly complete volunteer effort and things will add and
disappear over time as volunteers come in and out. We try to make it
stable and useful but we do not guarantee/promise/etc any Enterprise
level 'support'. If you are needing that then I would contract out for
it with someone who can do that kind of work... or come up with
techniques to mitigate changes that will occur in EPEL.
--
Stephen J Smoogen.
10:26 a.m.
On Dec 11, 2019, at 17:33, Stephen John Smoogen <smooge(a)gmail.com> wrote:
I want to correct one thing: EPEL is not an Enterprise repository.
It
is a nearly complete volunteer effort and things will add and
disappear over time as volunteers come in and out. We try to make it
stable and useful but we do not guarantee/promise/etc any Enterprise
level 'support'. If you are needing that then I would contract out for
it with someone who can do that kind of work... or come up with
techniques to mitigate changes that will occur in EPEL.
Thank you for the clarification. Very good to know!
Cheers!
|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|---------------------------------------------------------------------|
| A room without books is like a body without a soul. |
| |
| -- Cicero |
|---------------------------------------------------------------------|
1603
days inactive
1604
days old
epel-devel@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Fred Gleason -
Miro Hrončok -
Stephen John Smoogen