[Buildroot] Buildroot, github and nopullrequest.com

Angelo Compagnucci angelo.compagnucci at gmail.com
Sat Jul 16 16:52:24 UTC 2016


Dear Yann, All

2016-07-16 18:46 GMT+02:00 Yann E. MORIN <yann.morin.1998 at free.fr>:
> Angelo, All,
>
> On 2016-07-16 14:44 +0200, Angelo Compagnucci spake thusly:
>> Personally, I'm really sad that the buildroot infrastructure is
>> currently down from a few days, buildroot is such a wonderful project
>> that not merits such a shame.
>
> Yes, DDoS are painful... :-(
>
>> Obviously, the infrastructure behind buildroot is not up to date to
>> the current standards, I think we should change.
>
> That's something that had been floating for the past year or so...
>
>> So, I'm drafting a tentative approach, and I'm sharing it with you.
>> Obviously I'm not entitled in acting in any way, but hey, can I dream
>> for a better Buildroot?!
>
> Your input is much welcome! :-)
>
> We all believe self-hosting is a waste of time: it's too difficult, we
> don't really need it, and it would not be much better than what we have
> today. We all believe a forge of some sort is what we want to go to.
>
>> 1) Website: we have a github account, we have github pages, we should
>> switch there! The only downside here is that github pages doesn't
>> suppo SSI, so we should write a simple bash script to assemble the
>> website before publication. Github pages resides on their own
>> repository, so we can have the website as always in the main
>> repository and the bash script will assemble the website in an outside
>> directory where the other repository it's cloned.
>
> There is also Gitlab. I would favour Gitlab over github, if at least
> because it is an open source project, not a closed, walled garden like
> Github is. All things being equal, Gitlab is on par with github
> regarding the features we need, plus a killer one: we can disable PRs
> alltogether with Gitlab, which we can't with Github.

Could you point to some documentation on how to do that?! I'm
interested but I can find anything!

>
> And if we were ever to re-self-host, we could take the data as-is with
> our own instance of Gitlab. And even if moving to something else than
> Gitlab, taking the data out of Gitlab is easier than out of Github.
>
>> 2) We have a github account, we should use it as the main repository.
>> No other words here.
>
> Or Gitlab! ;-)
>
>> 3) Githb pull requests. Obviously, we won't github pull requests, and
>> here enters the game https://nopullrequests.com.
>
> Or Gitlab, which allows to disable PRs altogether.
>
>> It's a simple github
>> webhook that closes a PR with a message. The source is publicly
>> available on github. We can use that service as is, or run an instance
>> ourselves on GAE.
>
> As Thomas said, I'm not too comfortable with allowing a third party
> automatic access to our repo. Especially since it looks like it wants a
> Google account.
>
> As for running an instance ourselves, it would mean we self-host again,
> which wee don;t want.
>
>> I had a look at the source code and it's pretty
>> secure, once it's authorized on github, it receives a message on each
>> pull requests and replies immediately without keeping anything
>> (caching or disk). Hosting our instance on GAE will have the benefit
>> on personalizing the commit message with something more specific than
>> the pretty aseptic default message.
>>
>> 4) Issues: well, everything is better than bugzilla!
>
> Issues in Github are a pain IMHO: except for their "template", there is
> no possibility to have arbitrary fields. Git lab is not much better in
> this respect either.
>
> And there's still the emails for each commit: neither Github nor Gitlab
> can do that; they can only send an email per push, not per commit.
>
> However, with Gitlab, it looks like we could implement it and do a PR.
> With Github, there's no way we can do it.
>
>
> So, lemme recap:
>
>                             | Github            | Gitlab            |
> ----------------------------+-------------------+-------------------+
> License                     | Proprietary       | Open Source       |
> Network effect              | Definitely        | Somewhat          |
> git tree                    | Yes               | Yes               |
> Web pages                   | Static            | Static            |
> web hooks                   | Yes               | Yes               |
> C.I.                        | Yes, many [0]     | Yes, many [1]     |
> emails                      | on push           | on push [2]       |
> IRC                         | No?               | irker             |
> Markup language             | Markdown (MD)     | Markdown (MD)     |
> README                      | Yes, MD           | Yes, MD           |
> Issue tracker               | Yes, minimal, MD  | Yes, minimal, MD  |
> Snippets                    | Yes               | Yes               |
> Export project data         | No?               | Yes               |
>
>
> So there is no clear winner. The only things that would tip the scale is
> the license and the possibility to have per-commit emails.
>
> My favourite is obviously Gitlab. ;-)
>
>
> [0] of which, Travis
> [1] of which, Jenkins
> [2] The source code is available, we could do the modifications and
>     submit back to Gitlab; for now, I opened an issue there;
>     https://gitlab.com/gitlab-org/gitlab-ce/issues/19901
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo



More information about the buildroot mailing list