Thanks Miro. That's basically what I had in mind. I am waiting now to see how it will be but the most probably we switch to the original upstream. It seems that they will continue with versioning of the currently used upstream, so epocha will not be needed. Currently there is some syncing of repositories so I am waiting for the new release (I guess it is question of several weeks). (Currently, the package is broken now because of changes in the latest version of mercurial, so maybe I will do some fixes before that.) On 06. 06. 19 13:04, Miro Hrončok wrote: > 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. > -- Petr Stodulka OS & Application Modernization IRC nicks: pstodulk, skytak Software Engineer Red Hat Czech s.r.o.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
