Chronological Thread 

< Chronological >      < Thread >

---

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

---

• [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.