On 06. 06. 19 12:55, Petr Stodulka wrote: > 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. It's always a tough decision to make. It was not a mistake, you could not have known. 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.