Ok, a typical graph<div><a href="https://github.com/LearnBoost/socket.io/network">https://github.com/LearnBoost/socket.io/network</a></div><div>you can drag the graph, to scroll it</div><div><br></div><div>The fork level is usually only one level deep: core, and your fork.<br>
<br><div class="gmail_quote">On Sun, Dec 30, 2012 at 10:06 AM, Germán Arduino <span dir="ltr"><<a href="mailto:garduino@gmail.com" target="_blank">garduino@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm only a newbie with GitHub, really I don't know it deeper to have a valid opinion. But my main concern is (as in the list with the packages) forks and more forks seems not be very practical.....<div class="HOEnZb">
<div class="h5"><div><br><br><div class="gmail_quote">
2012/12/30 Angel Java Lopez <span dir="ltr"><<a href="mailto:ajlopez2000@gmail.com" target="_blank">ajlopez2000@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi people!<div><br></div><div>Yes, you usually work on master (it could be called the "developer branch"), and when you are ready, tag it. Ummm.. you tag your local repo, and then push the tags to Github. AFAIK, you could move the tag to other commit, for example, if there are a minor fix in documentation or something alike.</div>
<div><br></div><div>Having packages out of the central repo, is more agile.</div><div><br></div><div>Maybe a "solution at the middle": some "blessed" (easy to test, to load from core in central repo, many used, important for community, etc...) packages are at central repo, and the other packages are listed in a page</div>
<span><font color="#888888">
<div><br></div><div>Angel "Java" Lopez</div></font></span><div><span><font color="#888888">@ajlopez</font></span><div><div><br><br><div class="gmail_quote">On Sun, Dec 30, 2012 at 9:01 AM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Angel,<br>
<br>
I really like the idea of having a single and consistent git commit of a Cuis version and all the packages that work on it. It would make much easier to go back to some date, and grab stuff that works well together. One downside is a bit more work for repo admin. A bigger one is that it makes things a slower for package maintainers. But the consistency might outweigh them.<br>
<br>
Below, I extracted Angel's comments on this. Folks, please comment. Add steps or ideas to complete or enhance Angel's suggestion. Or if you don't like it, please say why. This is a rather important decision, and I'd like we to make a good choice.<br>
<br>
One quick question for Angel (I'm a beginner with github): Can we tag a commit after it was done? That way, we could work together on Cuis and Packages for several days (involving many commits) and only when we are all happy, we can tag the last one as "v4.1 with packages" or something like that.<br>
<br>
Cheers,<br>
Juan Vuletich<br>
<br>
Angel Java Lopez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br>
<br>
But having the central repo with the package (not a link), has an advantage: central repo could have tags. So, the packages at tag "v0.1.0" are all compatible with that tag, and every improvement at tag "v0.2.0" should be committed to that tag. The "master" tag is the development tag.<br>
<br>
So, I could download the v0.2.0 with all the optional packages of that version, without struggling going to each package author repo, and trying to guess what package/tag is compatible with Cuis v0.2.0<br>
<br>
Cons: it put more responsability to central repo author(s).<br>
<br>
<br>
<br>
2012/12/27 Angel Java Lopez <<a href="mailto:ajlopez2000@gmail.com" target="_blank">ajlopez2000@gmail.com</a><br>
<mailto:<a href="mailto:ajlopez2000@gmail.com" target="_blank">ajlopez2000@gmail.com</a>><u></u>><br>
<br>
Until you have a package manager, first idea:<br>
<br>
Use the cuis repo at GitHub.<br>
<br>
Every contributor make a fork.<br>
He/she add the code to his/her fork.<br>
Make a pull request to central repo<br>
<br>
Maybe, a guide to have folders per package/topic.<br>
...<br>
<br>
Angel "MyLifeIsGitHub" Lopez ;-)<br>
github:ajlopez<br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org" target="_blank">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/<u></u>listinfo/cuis_jvuletich.org</a><br>
</blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org" target="_blank">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div><br></div>
</div></div><br>_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
<br></blockquote></div><br></div>