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
IRC: mhroncok