Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 07. 08. 19 19:31, Petr Stodulka wrote:

On 07. 08. 19 3:34, Mads Kiilerich wrote:
On 8/6/19 9:35 PM, Petr Stodulka wrote:
So it's question, should I rebase it in rawhide and setup for Python3
already even when it is so broken, or


Hi

I agree that something like this kind of is the right thing to do. Mercurial upstream needs our help to get Python3 support out of beta. But it will be painful. For developers and users.

Yep. That's it. On the other hand, I am thinking now, whether people will have enough time to fix everything in case we will put it into the repo later. I mean, now there is enough time to work on that, bzt doing switch e.g. 3 months before release would generate more pressure on other maintainers.


It might get more attention if we take hostages and leave Mercurial broken for our users, but I would rather avoid that.

Right now all packages that depend on Mercurial are kind of blocked and can't migrate because there is no official package with Mercurial on Python3. I think the best way forward is to get it packaged for python3, next to the existing python2 package. Perhaps as a sub package, or perhaps as a separate package that can be patched and move fast. That will give us opportunity and freedom to experiment and migrate each dependent package as we see fit, with minimal negative impact on our users.

/Mads
packager, hgview and tortoisehg



I agree that that seems like best options for people,
but honestly I am not sure how much it worth to create
such packages and probably remove the old ones before
we release new system. I mean, from your email I guess
you mean something like this:
  - keep these python2 now:
       mercurial, mercurial-hgk, mercurial-*
  - create new subpkgs for python3
       mercurial3, mercurial3-hgk, mercurial3-*
  (or vice versa; mercurial for py3, and mercurial2 for py2)
Right? As we are talking about temporary state that will be
changed in several weeks (one of those groups will be dropped
before release of 31) and after that there will be additional
release/obsolete set, which jsut beause of that I am not so
big fun. I would honestly rather tell people they should use
copr builds instead. - or we can guide people in case of troubles
to switch to COPR repo for Python2 builds of mercurial and use
just the new in rawhide. That would be solution too. What do you
think about that?

I will be able to spent 1-2 nights with that next week again.
I am able to create the subpackages next week if needed but
I would go rather with ways where COPR is included (creating
mercurial group including all related people - maintainers -
to be able to work there and later switch in rawhide).

Currently, some additional packages that works with mercurial,
have to resolve the troubles already as dependencies for them
will be broken soon because of orphaned rpms.

I would like to hear even opinions of other people around,
especially people around mercurial (including mercurial
maintainers, guys?)


P.S. I apologize for long emails. I am too much talkative last days.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux