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?)
