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

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

 



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.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
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