Re: Question about working with upstream vs patches

[Troy Curtis Jr]

On Sat, Sep 2, 2017 at 7:40 AM Miro Hrončok  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

Re: Question about working with upstream vs patches

[Miro Hrončok]

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
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org