Howdy,
I'd like to help work toward the Fedora move toward Python 3. There is lots of good information out there about much of the process, but I did have a few questions about how you like to do things, and the proper work-flow.
If I start working on a particular package, should I mention as such in the associated porting bugtracker ticket? I could see it either way, either it needless clutters the ticket comments, or it is helpful for the next guy to pick a different package.
I already started looking at gpsd, since I've had some experience with it, and it is bound to be challenging! I was proven right pretty quickly. It is all perfectly workable, but I wanted to know the general expectation. For changes to python modules/scripts themselves to support python 3, does this need to flow through upstream in all cases? Most of my packaging experience has been with the enterprise distros, and there are always loads of patches carried along with the sources, but in this case do you require an official release from the upstream project with the necessary changes?
I certainly plan on providing all the changes upstream, but the last release was almost 2 years ago, so I'm not certain when a new one might be expected (the project is still active though).
Thanks, Troy Curtis
On 2.9.2017 05:53, Troy Curtis Jr wrote:
Howdy,
Hi Troy,
I'd like to help work toward the Fedora move toward Python 3. There is lots of good information out there about much of the process, but I did have a few questions about how you like to do things, and the proper work-flow.
This is always a great thing to hear. Welcome. Hopefully we will be able to help you with your questions.
If I start working on a particular package, should I mention as such in the associated porting bugtracker ticket? I could see it either way, either it needless clutters the ticket comments, or it is helpful for the next guy to pick a different package.
It's always helpful to say: "Hi, I'm going to work on this." It eliminates the possibility that some work is being done by multiple persons at the same time.
Also, it allows others to say things like: "Hey Troy, are you still working on this? What's your status?"
Don't worry about needless cluttering. Any information relevant to the ticket is good. Even if it says: "I'm still interested in this, but I haven't been able to progresses trough XYZ, as it seems I'm stuck at ABC."
I already started looking at gpsd, since I've had some experience with it, and it is bound to be challenging! I was proven right pretty quickly. It is all perfectly workable, but I wanted to know the general expectation. For changes to python modules/scripts themselves to support python 3, does this need to flow through upstream in all cases?
In 99.98% cases, it has to go trough upstream. I can see a situation, where patches are being reviewed upstream, likely to be accepted, but we need this in Fedora ASAP, so patches are applied in Fedora before accepted upstream. But that should only happen if this package is blocking other important packages. I think we did this with python-yubikey (not quite sure).
Applying Python 3 compatibility patches downstream only (i.e. only in Fedora, not yet proposed to upstream) is strongly discouraged. I would only see a fit there if there is already a python3-xyz package and in an update, it loses Python 3 compatibility by accident, users start filling bugs and everything is broken. In that case, I would see a situation where patching downstream first and proposing to upstream immediately after is a good way.
But if the python3-xyz package is not yet in Fedora, always go upstream first.
Doing Python 3 compatibility patches downstream only you are basically maintaining a fork. If you want to do that (sometimes you do, because upstream is dead or doesn't want Python 3), there are better places to maintain forks than Fedora spec + patches. This happened with python-ldap vs. python-pyldap (fork is maintained on GitHub).
Most of my packaging experience has been with the enterprise distros, and there are always loads of patches carried along with the sources, but in this case do you require an official release from the upstream project with the necessary changes?
Official release is the best. If the release will come late and the package is blocking something, taking patches form upstream version control system (e.g. git) and applying them to get Python 3 support might be applicable. (It happened in the past.) This always depends on the reason.
Consider those situations:
* Next release of xyz will be in 3 weeks and will bring Python 3 support.
* Next release of abc might happen in a year, if there are no serious problems. Python 3 support is in git master and will be only officially released in the next release. There are 5 packages that require abc and are Python 3 ready, only waiting for abc.
Those are obviously different. Always apply common sense.
I certainly plan on providing all the changes upstream, but the last release was almost 2 years ago, so I'm not certain when a new one might be expected (the project is still active though).
Get the patches to upstream. If accepted, talk to them about releasing. If they are reluctance to do a release soon, revisit this question.
Hope my answers were helpful. Find me or others on #fedora-python IRC channel if you need real time clarifications. (Or continue asynchronously trough e-mail.)
On Sat, Sep 2, 2017 at 7:40 AM Miro Hrončok mhroncok@redhat.com wrote:
On 2.9.2017 05:53, Troy Curtis Jr wrote:
Howdy,
Hi Troy,
I'd like to help work toward the Fedora move toward Python 3. There is lots of good information out there about much of the process, but I did have a few questions about how you like to do things, and the proper work-flow.
This is always a great thing to hear. Welcome. Hopefully we will be able to help you with your questions.
If I start working on a particular package, should I mention as such in the associated porting bugtracker ticket? I could see it either way, either it needless clutters the ticket comments, or it is helpful for the next guy to pick a different package.
It's always helpful to say: "Hi, I'm going to work on this." It eliminates the possibility that some work is being done by multiple persons at the same time.
Also, it allows others to say things like: "Hey Troy, are you still working on this? What's your status?"
Don't worry about needless cluttering. Any information relevant to the ticket is good. Even if it says: "I'm still interested in this, but I haven't been able to progresses trough XYZ, as it seems I'm stuck at ABC."
Sounds great, I'll put a comment on the ticket.
I already started looking at gpsd, since I've had some experience with it, and it is bound to be challenging! I was proven right pretty quickly. It is all perfectly workable, but I wanted to know the general expectation. For changes to python modules/scripts themselves to support python 3, does this need to flow through upstream in all cases?
In 99.98% cases, it has to go trough upstream. I can see a situation, where patches are being reviewed upstream, likely to be accepted, but we need this in Fedora ASAP, so patches are applied in Fedora before accepted upstream. But that should only happen if this package is blocking other important packages. I think we did this with python-yubikey (not quite sure).
Applying Python 3 compatibility patches downstream only (i.e. only in Fedora, not yet proposed to upstream) is strongly discouraged. I would only see a fit there if there is already a python3-xyz package and in an update, it loses Python 3 compatibility by accident, users start filling bugs and everything is broken. In that case, I would see a situation where patching downstream first and proposing to upstream immediately after is a good way.
But if the python3-xyz package is not yet in Fedora, always go upstream first.
Doing Python 3 compatibility patches downstream only you are basically maintaining a fork. If you want to do that (sometimes you do, because upstream is dead or doesn't want Python 3), there are better places to maintain forks than Fedora spec + patches. This happened with python-ldap vs. python-pyldap (fork is maintained on GitHub).
Makes perfect sense, I am just used to seeing the pile of patches in RPMs. I'll certainly start working with upstream on it.
Most of my packaging experience has been with the enterprise distros, and there are always loads of patches carried along with the sources, but in this case do you require an official release from the upstream project with the necessary changes?
Official release is the best. If the release will come late and the package is blocking something, taking patches form upstream version control system (e.g. git) and applying them to get Python 3 support might be applicable. (It happened in the past.) This always depends on the reason.
Consider those situations:
Next release of xyz will be in 3 weeks and will bring Python 3 support.
Next release of abc might happen in a year, if there are no serious
problems. Python 3 support is in git master and will be only officially released in the next release. There are 5 packages that require abc and are Python 3 ready, only waiting for abc.
Those are obviously different. Always apply common sense.
I certainly plan on providing all the changes upstream, but the last release was almost 2 years ago, so I'm not certain when a new one might be expected (the project is still active though).
Get the patches to upstream. If accepted, talk to them about releasing. If they are reluctance to do a release soon, revisit this question.
Hope my answers were helpful. Find me or others on #fedora-python IRC channel if you need real time clarifications. (Or continue asynchronously trough e-mail.)
I really appreciate the response, it certainly cleared things up. I'll also take a close look at the packages currently pointing to gpsd as a dependency. If they are not using the python scripts or bindings directly, then simply pulling the python bits out into a python2-gpsd package may be sufficient to break the bulk of the dependency chain. The I can work with upstream separately to get full python3 support working well.
Troy Curtis
-- Miro Hrončok -- Phone: +420777974800 <+420%20777%20974%20800> IRC: mhroncok
python-devel@lists.fedoraproject.org
-
Miro Hrončok -
Troy Curtis Jr