534
edits
Changes
Jump to navigation
Jump to search
Infrastructure Team/Migrating to GitHub (view source)
Revision as of 11:35, 17 May 2016
, 11:35, 17 May 2016In
== Sugar Activities Developers: Take 10 Minutes to move to Github Today! ==
Part of the vision of Sugar Labs is to introduce young people to the software freedom movement.
A successful introduction means they are actively participating in Sugar's development, and the wider libre software world.
The majority of libre software in 2016 is developed on Github, and it advances our cause to use the same collaboration platform as most other project use.
The Sugar codebase has begun transitioning to Github in [https://www.github.com/sugarlabs www.github.com/sugarlabs].
So we now invite all Activity developers to do 2 things to complete this transition.
This should take you no more than 10 minutes:
1. Migrate your project source code and issue tracking to Github (https://help.github.com/articles/create-a-repo)
2. Once your project is set up as a Github Repo, please transfer it to github.com/sugarlabs so it is more discoverable (https://help.github.com/articles/transferring-a-repository/)
After the transfer, we'll update the activity.info file of the activity itself with the new URL
We'll also invite your Github username to join the [https://www.github.com/sugarlabs github.com/sugarlabs] organization, so you can transfer activities to yourself.
No longer involved? To pass your Activity on to the community to maintain, drop a line to <sugar-devel@lists.sugarlabs.org>.
If you read this well after May 2016, we may have already forked your repo into the org to maintain an 'official' copy of it, but transferring is better than forking so that Github shows the sugarlabs repo as the 'upstream' repo on network graph pages ([https://github.com/sugarlabs/sugar/network example])
New to Github? Check their excellent documentation at guides.github.com, help.github.com, try.github.io
=== Details ===
All our code, bugs and discussions should be in one place.
In 2013 Sugar's core components moved from http://git.sugarlabs.org/sugar-old to https://github.com/sugarlabs/sugar, but all issue tracking stayed at bugs.sugarlabs.org instead of moving to https://github.com/sugarlabs/sugar/issues and some code stayed in git.sugarlabs.org and some moved to personal Github username areas.
This scattering
* deters new contributors;
* makes existing contributor's lives more painful;
* wastes time from our systems team volunteers (as we have a hard time keeping hackers out of trac, and need to spend time upgrading any service we run ourselves)
Two solutions have been proposed:
;1. Consolidate on Github:Set trac and gitorious read only, and then making it a static html archive, while moving all issue tracking and git hosting of each sugar repo to Github.
;2. Abandon Github:Consolidate on our own systems; I guess this means setting up gogs or gitlab to replace gitorious, and perhaps something else to replace trac, and then removing each sugar repo from Github that we control, and regularly encouraging all sugar activities on github to move to our infrastructure.
The developer community has discussed this ([http://lists.sugarlabs.org/archive/sugar-devel/2016-April/thread.html#51788 thread]) and reached consensus in favour of (1) with the following comments:
=== Benefits of Github Consolidation ===
;Notification: This is handled due to the way that Github org membership works. Github-users in a 'developers' Github-team within the Github-organization will be emailed all posts to all repos that are added to that team (done here, http://imgur.com/gUTNFfV)
;Search: Github provides org-wide search, and this is discoverable when you visit github.com/sugarlabs the search input widget at the top changes to show that the search is scoped to that organization. After entering a search query, a familiar search syntax is used in the query, and in the URL string. Eg, https://github.com/search?q=org%3Afontforge+x11&type=Issues
;Discoverability: It will be easier for new developers to find and contribute if Sugar is all on github.
* Github allows us to separate issue into separate Sugar and Sugar Activity trackers, trackers are found predictably at github.com/sugarlabs/activity-name/issues
* It serves as an issue aggregation tool, as all issue trackers in the github.com can be searched by visiting github.com/sugarlabs and using the search input at the very top of the page ([https://github.com/search?q=org%3Asugarlabs&ref=searchresults&type=Issues&utf8=%E2%9C%93 example])
* https://github.com/sugarlabs/sugar/issues/ can be used as a default issue tracker, if there is any ambiguity on where to file an issue
* Issues on Github can be linked to pull requests that resolve them (and even close them automatically by including "closes #issue_id" in the commit/pr message)
* Github automatically places backlinks in issues that are referred to by other issuer or PRs, it is relatively convenient to manage the set of a github organization's per-repo issue trackers. Github makes this easy because it will add backlinks in the destination issue's timeline when that issue is mentioned in the original; and it will automatically create such links if you type user/repo#issueNumber :) As an example of this back-linking, see these 2 links, https://github.com/llaske/sugarizer/issues/49 (link at end of first post) and https://github.com/mattlag/Glyphr-Studio/issues/234 (currently link is at the bottom :)
;Focus: SugarLabs should focus on core-competencies. Managing version control servers shouldn't be one of them. Support for "how to use git" would be mostly on github rather than SugarLab's systems
;Developer Preference: Getting existing Github users to move their activities out of Github doesn't seem realistic. Developers know that Github is stable and has security and longevity. People new to Github have a wider interest in signing up for it - because almost all other libre software projects that they will interact with are currently on the service.
;Viability: There are only [https://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&order=priority 182 open issues on bugs.sugarlabs.org] so moving them over can be done in a day
;Automation: Github enables easier automation of the release process, and easier tying of Sugar Activity version numbers to moments in git commit histories.
;Fully Featured: Github doesn't exclude users from features based on their ability to pay; all features are available to non-paying users. Instead of charging for features, they require non-paying users to have all their repos be public; the only thing that they charge for is how many users can participate in private repos. https://github.com/pricing/plans explains this, and there are no gotchas.
;Pseudonymity: Github does not require real names. To maintain pseudonymity, you can sign up using http://mailinator.com or a github-specific disposable email account.
== Further Actions For The Sugar Labs Team ==
* Set up a "full notifications" team in the github organization so that all github users that join this team get emailed every issue, pr, and comment for every github project within the organization.
* Configure all non-github issue trackers to prominently direct users to the new github url, and disallow new issues, or simply to have their theme templates hide the 'new issue' link, and eventually to be configured read only and then fully archived by conversion to a static HTML site.
* Review the wiki and website advising users where to post an issue, and update to point to Github
* Write a py/js script that uses the Github API to check issue tags are consistent across all SL repos; this can start with a manual checklist to run through when accepting a repo transfer to the sugarlabs org. Also, ensure each activity's /README.md file (that Github presents on github.com/sugarlabs/activity-name as processed markdown) has explicit information about standard things, like where its issue tracker is.
* Once all activities are migrated to Github, set the Gitorious and Trac instances to be read-only.
Part of the vision of Sugar Labs is to introduce young people to the software freedom movement.
A successful introduction means they are actively participating in Sugar's development, and the wider libre software world.
The majority of libre software in 2016 is developed on Github, and it advances our cause to use the same collaboration platform as most other project use.
The Sugar codebase has begun transitioning to Github in [https://www.github.com/sugarlabs www.github.com/sugarlabs].
So we now invite all Activity developers to do 2 things to complete this transition.
This should take you no more than 10 minutes:
1. Migrate your project source code and issue tracking to Github (https://help.github.com/articles/create-a-repo)
2. Once your project is set up as a Github Repo, please transfer it to github.com/sugarlabs so it is more discoverable (https://help.github.com/articles/transferring-a-repository/)
After the transfer, we'll update the activity.info file of the activity itself with the new URL
We'll also invite your Github username to join the [https://www.github.com/sugarlabs github.com/sugarlabs] organization, so you can transfer activities to yourself.
No longer involved? To pass your Activity on to the community to maintain, drop a line to <sugar-devel@lists.sugarlabs.org>.
If you read this well after May 2016, we may have already forked your repo into the org to maintain an 'official' copy of it, but transferring is better than forking so that Github shows the sugarlabs repo as the 'upstream' repo on network graph pages ([https://github.com/sugarlabs/sugar/network example])
New to Github? Check their excellent documentation at guides.github.com, help.github.com, try.github.io
=== Details ===
All our code, bugs and discussions should be in one place.
In 2013 Sugar's core components moved from http://git.sugarlabs.org/sugar-old to https://github.com/sugarlabs/sugar, but all issue tracking stayed at bugs.sugarlabs.org instead of moving to https://github.com/sugarlabs/sugar/issues and some code stayed in git.sugarlabs.org and some moved to personal Github username areas.
This scattering
* deters new contributors;
* makes existing contributor's lives more painful;
* wastes time from our systems team volunteers (as we have a hard time keeping hackers out of trac, and need to spend time upgrading any service we run ourselves)
Two solutions have been proposed:
;1. Consolidate on Github:Set trac and gitorious read only, and then making it a static html archive, while moving all issue tracking and git hosting of each sugar repo to Github.
;2. Abandon Github:Consolidate on our own systems; I guess this means setting up gogs or gitlab to replace gitorious, and perhaps something else to replace trac, and then removing each sugar repo from Github that we control, and regularly encouraging all sugar activities on github to move to our infrastructure.
The developer community has discussed this ([http://lists.sugarlabs.org/archive/sugar-devel/2016-April/thread.html#51788 thread]) and reached consensus in favour of (1) with the following comments:
=== Benefits of Github Consolidation ===
;Notification: This is handled due to the way that Github org membership works. Github-users in a 'developers' Github-team within the Github-organization will be emailed all posts to all repos that are added to that team (done here, http://imgur.com/gUTNFfV)
;Search: Github provides org-wide search, and this is discoverable when you visit github.com/sugarlabs the search input widget at the top changes to show that the search is scoped to that organization. After entering a search query, a familiar search syntax is used in the query, and in the URL string. Eg, https://github.com/search?q=org%3Afontforge+x11&type=Issues
;Discoverability: It will be easier for new developers to find and contribute if Sugar is all on github.
* Github allows us to separate issue into separate Sugar and Sugar Activity trackers, trackers are found predictably at github.com/sugarlabs/activity-name/issues
* It serves as an issue aggregation tool, as all issue trackers in the github.com can be searched by visiting github.com/sugarlabs and using the search input at the very top of the page ([https://github.com/search?q=org%3Asugarlabs&ref=searchresults&type=Issues&utf8=%E2%9C%93 example])
* https://github.com/sugarlabs/sugar/issues/ can be used as a default issue tracker, if there is any ambiguity on where to file an issue
* Issues on Github can be linked to pull requests that resolve them (and even close them automatically by including "closes #issue_id" in the commit/pr message)
* Github automatically places backlinks in issues that are referred to by other issuer or PRs, it is relatively convenient to manage the set of a github organization's per-repo issue trackers. Github makes this easy because it will add backlinks in the destination issue's timeline when that issue is mentioned in the original; and it will automatically create such links if you type user/repo#issueNumber :) As an example of this back-linking, see these 2 links, https://github.com/llaske/sugarizer/issues/49 (link at end of first post) and https://github.com/mattlag/Glyphr-Studio/issues/234 (currently link is at the bottom :)
;Focus: SugarLabs should focus on core-competencies. Managing version control servers shouldn't be one of them. Support for "how to use git" would be mostly on github rather than SugarLab's systems
;Developer Preference: Getting existing Github users to move their activities out of Github doesn't seem realistic. Developers know that Github is stable and has security and longevity. People new to Github have a wider interest in signing up for it - because almost all other libre software projects that they will interact with are currently on the service.
;Viability: There are only [https://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&order=priority 182 open issues on bugs.sugarlabs.org] so moving them over can be done in a day
;Automation: Github enables easier automation of the release process, and easier tying of Sugar Activity version numbers to moments in git commit histories.
;Fully Featured: Github doesn't exclude users from features based on their ability to pay; all features are available to non-paying users. Instead of charging for features, they require non-paying users to have all their repos be public; the only thing that they charge for is how many users can participate in private repos. https://github.com/pricing/plans explains this, and there are no gotchas.
;Pseudonymity: Github does not require real names. To maintain pseudonymity, you can sign up using http://mailinator.com or a github-specific disposable email account.
== Further Actions For The Sugar Labs Team ==
* Set up a "full notifications" team in the github organization so that all github users that join this team get emailed every issue, pr, and comment for every github project within the organization.
* Configure all non-github issue trackers to prominently direct users to the new github url, and disallow new issues, or simply to have their theme templates hide the 'new issue' link, and eventually to be configured read only and then fully archived by conversion to a static HTML site.
* Review the wiki and website advising users where to post an issue, and update to point to Github
* Write a py/js script that uses the Github API to check issue tags are consistent across all SL repos; this can start with a manual checklist to run through when accepting a repo transfer to the sugarlabs org. Also, ensure each activity's /README.md file (that Github presents on github.com/sugarlabs/activity-name as processed markdown) has explicit information about standard things, like where its issue tracker is.
* Once all activities are migrated to Github, set the Gitorious and Trac instances to be read-only.