On Sat, Sep 2, 2017 at 7:40 AM Miro Hrončok <mhron...@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 mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
