7:40 a.m.
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.)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok