Re: Migrate to github

[Vincent Torri]

On Mon, Aug 17, 2020 at 10:54 PM Anurag Thakur
<devanuragthakur@gmail.com> wrote:
>
> (I searched the mailing list archives, but could not find anything related to 
> this topic, so here goes: )
>
> Freetype is an essential library, generating what billions of eyes see 
> worldwide everyday, this means that any improvement made here would have a 
> huge impact all around the world. It also means that it is an attractive 
> attack vector for hackers, so the code must be bug free. I believe that the 
> current development setup is suboptimal for a library this important and 
> would like to suggest some improvements.
>
> #1: Migrate development over to github:
> Host the git repo on GitHub, use the GitHub issues and PR tracker instead of 
> GNU Savannah and e-mail
>
> Benefits:
> 1. Makes contribution easier:
> GitHub is the most popular code hosting platform used by millions of 
> projects, and as a result, most open-source developers already know how to 
> use it, reducing the need to learn new tooling as compared to GNU Savannah 
> and email which are much less common.
>
> 2. Visibility:
> It is much easier for a curious developer to navigate a GitHub repository 
> than to clone the repo and scour mailing lists looking for patches and code 
> reviews.
>
> 3. Easier for newbies :
> GitHub has *excellent* documentation about almost everything related to git 
> and GitHub, so new developers can get acquainted with version control easily 
> and quickly. It should also help GSOC students focus on their task instead of 
> navigating around obsolete UI.
>
> 4. Attracts younger developers:
> Stuff like hacktoberfest, the GitHub student developer pack ensures student 
> Dev's from around the world are on GitHub, effectively increasing potential 
> contributors. Even if not code, it makes it easier for developers to just 
> stop by and give suggestions in comments to PRs or issues.
>
> 5. Productivity features:
> GitHub has many features that make contributing to as well as reviewing code 
> easier. A beautiful interface, code review tools to suggest changes per 
> line!, a powerful issue tracker with labels, duplicates, milestones etc., 
> ability to create a wiki, managing releases, a mobile app so you can post 
> suggestions on open issues while laying on your bed!! etc.
>
> It even has a cli!!
>
>
> Overall, it is much easier to open issues on GitHub, send patches via PRs and 
> the tight integration means you can easily manage PRs that close specific 
> issues, milestones etc.
>
> #2: Join GitHub sponsors program:
> Text rendering has a profound impact on the user experience and there would 
> be many people willing to sponsor improvements to text rendering, 
> particularly linux folks, so it would be great if there was a way to channel 
> their support.
>
> Benefits:
> Increase incentive for developers to contribute to freetype, the money could 
> be used to hire part time devs, support website infrastructure, etc.
>
> #3: Use GitHub actions:
> GitHub actions can be used to setup a ci for freetype and make issue/PR 
> tracking easier with bots.
>
> Benefits:
> You can have all kinds of testing and fuzzing for all supported architectures 
> *for free* , this would be very helpful in improving code quality and 
> preventing regressions, and would ultimately lead to increase in robustness 
> of the library. It would also be helpful in automating workflows, for example 
> generating docs on a new release using GitHub actions with freetype-docwriter.
>
> Overall, the proposed changes would decrease friction for new developers, 
> increase the amount of contributions, incentivise development, and provide a 
> pleasent user interface for code contribution, review and management.
>
>
> There are many successful FOSS projects being developed on GitHub: opencv, 
> harfbuzz, curl, rust, vscode and thousands more, so it would be great to join 
> them.
>
> These are my points (I am a newbie too), I hope this post starts a discussion 
> and we are able to reach a conclusion.

you mentioned ci (there are several ones) but in addition : coverity
(static analysis) and coveralls (API coverage)

regards

Vincent Torri