Bumping a thread five years later... and just FYI, Python has moved to Github: https://github.com/python/cpython The story behind the move: https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/
I'm not sure if the LyX team knows more about Github or has more interest now, but I still believe Github is a better choice than maintaining everything (GIT, Wiki, Trac, and so on) by yourselves, and you are more likely to attract talents who are willing to contribute to this project in the future. That said, I'm not as eager as I was five years ago to convince you guys, since I rarely use LyX or LaTeX directly now (but LyX is still *the* best frontend for LaTeX in my mind). If there is an intention to move, great, and let me know if there is anything I can help, otherwise it is totally fine, too. Disclaimer: I'm not affiliated with Github in any sense. I'm just an ordinary user who happens to have benefited a lot from it when developing open source software. Regards, Yihui -- https://yihui.name On Fri, Mar 2, 2012 at 9:25 PM, Yihui Xie <x...@yihui.name> wrote: > Well, I think I understand some of the advantages of GIT like easy > branching. I do not even bother to compare it to SVN because GIT is so > much better. > > I mean GitHub makes GIT even better; there are too many advantages and > I just list a few of them here: > > 1. developers manage their own SSH keys on GitHub and you do not need > to ask them to submit their public keys to you; > > 2. people who are not in the developer team can fork the project with > one-click to their own repositories, change the code and send pull > request online (instead of emailing patches) so that you can review > the patch online; a very critical feature here is you can _discuss_ > the code line by line with the one who submit this patch -- comments > can be made in-between the code lines; if you are not satisfactory > with the patch, you can require one to revise the code and resubmit; > this process can go on and on until you are satisfied and accept the > patch; see here for an example of my own: > https://github.com/ramnathv/knitr/commit/33a75f4029 > > Personally I believe it is very inefficient to email patches and it is > so inconvenient to discuss code in emails. If people send me pull > requests on GitHub, I may merge them in a few minutes, but patches in > email often lay in my inbox for months. > > 3. you can either discuss on GitHub pages, or directly reply the email > notifications from GitHub about the discussions; the email will go to > GitHub. This is unlike trac, you have to go to the web page to discuss > (maybe there are configurations that enable trac to manage emails, but > I did not see this happen in LyX SVN ages). > > 4. bugs tracker; they call "issues", which are also closely tied to > code; you can write a commit message like "fixed #43" to fix the issue > 43 (the issue will be closed and there will be a reference to the > commit in the issue page); it is also more convenient to manage bug > reports: one thing I do not like trac is I'm unable to change the > report after I submit it (e.g. I want to add more code examples, or > fix typos). > > 5. wiki support: you can manage wiki pages by GIT, or edit them > online; the default aesthetics looks good (e.g. > https://github.com/yihui/formatR/wiki) > > 6. GitHub pages: you can even manage your website on GitHub by > creating a branch named "gh-pages" and use the Jekyll engine to > compile markdown files to HTML (this is automatic on GitHub so you > only maintain lightweight markdown files); it is easy to setup and > after that, you can manage the website by GIT (see, everything on > GitHub can go to GIT); sorry to use my own projects as examples again, > but you can see the source > https://github.com/yihui/knitr/tree/gh-pages of the site > http://yihui.name/knitr/ for example > > Here is a recent article "Lord of the Files: How GitHub Tamed Free > Software (And More)": > http://www.wired.com/wiredenterprise/2012/02/github/all/1 > > In short, this is approximately true for me: GitHub = GIT + Trac + > Wiki + Web and all are based on GIT. Anyway, this is just my 2 cents > when I saw the transition from SVN to GIT, and of course you are free > to invest time and efforts in setting up your own server. > > Regards, > Yihui > -- > Yihui Xie <xieyi...@gmail.com> > Phone: 515-294-2465 Web: http://yihui.name > Department of Statistics, Iowa State University > 2215 Snedecor Hall, Ames, IA > > > > On Fri, Mar 2, 2012 at 4:01 AM, Vincent van Ravesteijn <v...@lyx.org> wrote: >> Op 2-3-2012 7:35, Yihui Xie schreef: >>> >>> I was actually wondering why not move to GitHub directly since >>> everything is ready there and it saves a huge amount of server admin >>> efforts... Maybe I missed some conversations earlier, but IMHO GitHub >>> makes collaborations way way easier. >>> >> >> In what sense does it make it easier ? Pull requests are nice, but this >> requires all developers to read the mailing lists and to keep track of any >> pull requests on github. It's easy to submit patches to the mailing list >> using "git send-email". In this way, all developers can respond. >> >> Using git, you could acquire commit rights faster than using svn, because at >> first you will be restricted to pushing branches like >> "yihuixie/new-feature". This won't affect the source code until it gets >> merged in by someone. >> >> Vincent
