what to do when original upstream recover from death?

Hi guys,
I have one curious question about the current situation around git-remote-hg.
To put you into the context, the solution was originally part of the git
upstream itself and several years ago has been split into the own upstream [0].

After a time, the upstream[0] did last commit in Sep27 2016 and since the date
Jan 24 2018 the account has been no active till this april. After a long time
has been started discussion about change to new upstream [1] which was active
and responding. Nowadays, this "new upstream" provides the git-remote-hg in pypi
and it is marked by Github as "source-repo" - the original one [0] is marked as
clone nowadays by Github.

I decided to switched into the upstream [1] on Aug 20 2018 from that point as
did several other projects. But several days ago the original upstream has
started to be active again. I guess that guys will make an agreement to setup
the original upstream back to [0], but currently it looks that original
upstream[0] do not care about the releases of new upstream that has been done
meanwhile and probably will continue with own versioning. I am trying
to discuss that to not have mix of same versions for different code. Not sure
whether I will be successful from that point.

I expect that we will have to move back to the original upstream[0] anyway in
Fedora, and in such case probably I will have to raise epoch in case of
discontinuation in current versioning.

My question is, do you have any related experience to the topic? I already
had some exprience with death upstreams, but this is really new to me.
As well, I am curious whether I did mistake when I switched to the
upstream[1] regarding the situation there was about the project.

Thanks for sharing your ideas,

[0] <a href="" title=""></a>
[1] <a href="" title=""></a>


Re: what to do when original upstream recover from death?

By =?UTF-8?B?TWlyb... at 06/06/2019 - 07:04

On 06. 06. 19 12:55, Petr Stodulka wrote:
It's always a tough decision to make. It was not a mistake, you could not have

I recommend the following:

1. make the upstreams talk to each other
2. make the upstreams talk to each other
3. make the upstreams talk to each other
4. if the above fails, pick the once that would benefit the most users
5. but keep an eye on the other one in case it changes
(but don't switch there and back every month)
6. make the upstreams talk to each other

Hope that helps.