Chronological Thread 

< Chronological >      < Thread >

---

Hi!

I find the process of forking *everything* we use is somewhat
paranoid, but then again it has never happened to me that a project I
use got deleted while I was using it. So from that point of view,
forking doesn't hurt. :)

What is a little problematic is the fact that we *use* these forks in
production. This forces us to keep them updated manually which doesn't
happen now. For example peerlibrary/meteor-file lags 5 commits behind
upstream and same can be said for all forks I think.

Also, the current workflow actually encourages working in the forks
instead of pushing the changes upstream. For example,
peerlibrary/meteor is 55 commits ahead of meteor/meteor, and I for one
have no idea how to get the changes upstream. We are now running on an
actual fork, and it will require work to hop back on meteor/meteor.

As a remedy, one could create the forks (and have them synced every 5
minutes by a cronjob -- I could set this up) and leave them wherever
they are as fallback -- possibly even a different GitHub organization.
If we need functionality in upstream packages, development goes
upstream by the regular fork-branch-pullrequest workflow we all know
and are familar with. This keeps the code we depend on safe and makes
sure we don't divert too much from upstream.

What do you think?

--Nico



On Fri, Aug 22, 2014 at 7:19 PM, Mitar
< >
wrote:
> Hi!
>
>> there's also a bunch of other forks in the peerlibrary github orga, e.g.
>
> We fork every dependency we have. So when we are starting to use a
> package, we fork it as well. Does not matter if we have or don't have
> changes done to the repository. The reason we fork it is because
> sometimes upstream repository gets deleted and then you have project
> which does not work anymore (people decide to abandon the package, move
> elsewhere in their life, clean-up GitHub, etc.). This happened to me in
> the past, so now I am forking everything to have our own copy.
>
> (The minus is that we fork first time, but don't really keep it in sync
> and update it from upstream, even if our dependency in smart.json uses
> newer version. Somebody could write a script which goes over all our
> forked package repositories and pulls in new changes. Or maybe there is
> some service for that? I really don't know why GitHub does not do this
> automatically.)
>
>> Many of them have only one or a few commits and don't have pending pull
>> requests. We should merge these changes upstream (if they're still
>> relevant). For the future, we should take care that pull requests are
>> issued immediately.
>
> You can see which forks we really use from looking into smart.json where
> we are using our fork git repository. The others we are not using as
> forks, but just storing as described above.
>
> For those where we changed something, the process is as follows. We
> leave upstream branches as they are and fork from their integration
> branch (master or devel or whatever) a new feature branch with our fix.
> We fix the thing and create an upstream pull request. Then, we have a
> special branch called "peerlibrary", which is their stable version +
> merged all needed feature branches we need (there are sometimes more
> than one fix we send upstream, we send them in separate pull requests,
> but we of course need all of them). This is the branch and version we
> are then using in smart.json and PeerLibrary.
>
> As you see, the whole process is centered around sending everything
> upstream. Sometimes you will see in our forked repositories changes
> which were already merged upstream (so check with smart.json if we are
> using our fork really). Sometimes things do not get merged upstream. So
> some things in Meteor I think are not merged. (Some probably never be,
> because are in contrast with their approach, or are just a temporary fix
> until there is a more generic solution suitable for the framework and
> not just us.) And there are some changes to meteor-router (which is not
> maintained anymore, so they do not accept changes anymore).
>
> But I would ask you to go over all those repositories and analyze. Are
> there things which have not been merged upstream, are there things which
> we have not made pull requests (I doubt so). Maybe update all our forks
> with new changes from upstream (but don't update the peerlibrary branch,
> only their original branches, for peerlibrary branch it means updating
> to new version which might break things and for now we are just before
> release of 0.3, so leave thins be).
>
>
> Mitar
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>
> Settings and unsubscription:
> http://lists.peerlibrary.org/lists/info/dev
>
> Public archive:
> http://lists.peerlibrary.org/lists/arc/dev

---

• [PeerLibrary dev] peerlibrary/meteor vs. meteor/meteor, Nico Schlömer, 08/22/2014
  • Re: [PeerLibrary dev] peerlibrary/meteor vs. meteor/meteor, André Gaul, 08/22/2014
    • Re: [PeerLibrary dev] peerlibrary/meteor vs. meteor/meteor, Mitar, 08/22/2014
      • Re: [PeerLibrary dev] peerlibrary/meteor vs. meteor/meteor, Nico Schlömer, 08/22/2014
        • Re: [PeerLibrary dev] peerlibrary/meteor vs. meteor/meteor, Mitar, 08/22/2014
          • Re: [PeerLibrary dev] peerlibrary/meteor vs. meteor/meteor, Mitar, 08/22/2014

---

Archive powered by MHonArc 2.6.18.