[Buildroot] Buildroot, github and nopullrequest.com

[Buildroot] Buildroot, github and nopullrequest.com

[Angelo Compagnucci]

Dear All,

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.

Obviously, the infrastructure behind buildroot is not up to date to
the current standards, I think we should change.

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?!

So, we have four aspects here to think about:

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.

2) We have a github account, we should use it as the main repository.
No other words here.

3) Githb pull requests. Obviously, we won't github pull requests, and
here enters the game https://nopullrequests.com. 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. 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!

Again, no intention to start a flame war here, only getting a better Buildroot!

Sincerely, Angelo

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

[Buildroot] Buildroot, github and nopullrequest.com

[Thomas Petazzoni]

Hello,

On Sat, 16 Jul 2016 14:44:06 +0200, Angelo Compagnucci wrote:

> 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.

Agreed.

> Obviously, the infrastructure behind buildroot is not up to date to
> the current standards, I think we should change.

I also agree.

> 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.

I just created https://github.com/buildroot/buildroot.github.io for
this purpose, and then realized that we use SSI includes. I think we
should probably move away from SSI includes, to a more modern web-site
generation mechanism, like Pelican (http://blog.getpelican.com/) or
similar.

> 2) We have a github account, we should use it as the main repository.
> No other words here.

Well, there is one *big* issue: e-mail notifications. They are not
available by default, and the only thing that people have been able to
do so far is to have notifications with one e-mail per push (i.e one
e-mail covering potentially multiple commits). This is definitely not
acceptable, and is a show-stopper to moving to github.

> 3) Githb pull requests. Obviously, we won't github pull requests, and
> here enters the game https://nopullrequests.com. 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. 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.

I'm not sure I like giving access to https://nopullrequests.com to my
Google account.

> 4) Issues: well, everything is better than bugzilla!
> 
> Again, no intention to start a flame war here, only getting a better Buildroot!

There are a few more things to think about:

 1/ The mailing list. I would suggest to move to lists.infradead.org,
    which is used by numerous Linux kernel communities. We would also
    use git.infradead.org as the Git repository, but then we wouldn't
    have an issue tracker. Of course, if we move the mailing list to a
    new location, the mailing list archives should be imported in the
    new location as well.

 2/ Migration of the bug tracker history. How do we move Bugzilla
    entries to the Github issue tracker? All references of bug tracker
    entries in Buildroot commits would become wrong. Not nice.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Buildroot, github and nopullrequest.com

[Angelo Compagnucci]

Dear Thomas, All

2016-07-16 15:09 GMT+02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Sat, 16 Jul 2016 14:44:06 +0200, Angelo Compagnucci wrote:
>
>> 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.
>
> Agreed.
>
>> Obviously, the infrastructure behind buildroot is not up to date to
>> the current standards, I think we should change.
>
> I also agree.
>
>> 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.
>
> I just created https://github.com/buildroot/buildroot.github.io for
> this purpose, and then realized that we use SSI includes. I think we
> should probably move away from SSI includes, to a more modern web-site
> generation mechanism, like Pelican (http://blog.getpelican.com/) or
> similar.

I'm not too familiar with these systems. Usually they are not too
flexibles and they tend make difficult to write your own theme for the
website. Thay are also blog oriented and not too much website
oriented.

>> 2) We have a github account, we should use it as the main repository.
>> No other words here.
>
> Well, there is one *big* issue: e-mail notifications. They are not
> available by default, and the only thing that people have been able to
> do so far is to have notifications with one e-mail per push (i.e one
> e-mail covering potentially multiple commits). This is definitely not
> acceptable, and is a show-stopper to moving to github.

I didn't realized github is so limited ...

>> 3) Githb pull requests. Obviously, we won't github pull requests, and
>> here enters the game https://nopullrequests.com. 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. 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.
>
> I'm not sure I like giving access to https://nopullrequests.com to my
> Google account.

You can jump that step, the important is to give the permission to
close the PRs (github permission). Obviously is not the most clean
solution, but the only viable one.

>> 4) Issues: well, everything is better than bugzilla!
>>
>> Again, no intention to start a flame war here, only getting a better Buildroot!
>
> There are a few more things to think about:
>
>  1/ The mailing list. I would suggest to move to lists.infradead.org,
>     which is used by numerous Linux kernel communities. We would also
>     use git.infradead.org as the Git repository, but then we wouldn't
>     have an issue tracker. Of course, if we move the mailing list to a
>     new location, the mailing list archives should be imported in the
>     new location as well.

I had a look at infradead.org and to it seems way less solid than the
infrastructure we have now. On the homepage
(http://www.infradead.org/) the author seems to look for a job ...

>  2/ Migration of the bug tracker history. How do we move Bugzilla
>     entries to the Github issue tracker? All references of bug tracker
>     entries in Buildroot commits would become wrong. Not nice.

Right, good catch.

Very intricate problem ...

>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



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

[Buildroot] Buildroot, github and nopullrequest.com

[Thomas Petazzoni]

Hello,

On Sat, 16 Jul 2016 15:58:35 +0200, Angelo Compagnucci wrote:

> > I just created https://github.com/buildroot/buildroot.github.io for
> > this purpose, and then realized that we use SSI includes. I think we
> > should probably move away from SSI includes, to a more modern web-site
> > generation mechanism, like Pelican (http://blog.getpelican.com/) or
> > similar.  
> 
> I'm not too familiar with these systems. Usually they are not too
> flexibles and they tend make difficult to write your own theme for the
> website. Thay are also blog oriented and not too much website
> oriented.

Then you indeed don't know such systems very well, because they tend to
be quite flexible. For example, the https://2016.capitoledulibre.org/
(french) website is generated by Pelican.

> >> 2) We have a github account, we should use it as the main repository.
> >> No other words here.  
> >
> > Well, there is one *big* issue: e-mail notifications. They are not
> > available by default, and the only thing that people have been able to
> > do so far is to have notifications with one e-mail per push (i.e one
> > e-mail covering potentially multiple commits). This is definitely not
> > acceptable, and is a show-stopper to moving to github.  
> 
> I didn't realized github is so limited ...

That's a very strong issue with Github. Until this is resolved, no way
we can switch to Github.

> > I'm not sure I like giving access to https://nopullrequests.com to my
> > Google account.  
> 
> You can jump that step, the important is to give the permission to
> close the PRs (github permission). Obviously is not the most clean
> solution, but the only viable one.

Not sure what you mean, but:

 * The https certificate of nopullrequests.com is invalid.

 * If I say "No thanks" when it asks me to log in with my Google
   account, it just redirects me to the Google homepage. Not very
   useful.

> I had a look at infradead.org and to it seems way less solid than the
> infrastructure we have now. On the homepage
> (http://www.infradead.org/) the author seems to look for a job ...

Well, if you search a bit, the guy in question is David Woodhouse
(https://www.linkedin.com/in/dwmw2). He has worked at RedHat for 8
years, and now is at Intel since 8 years. Not sure he is looking for a
job.

infradead.org is used for the ARM kernel mailing list, which receives
much more traffic than the Buildroot one. The Git infrastructure of
infradead is also widely used by kernel people. Grep "infradead.org" in
the kernel MAINTAINERS file.

> >  2/ Migration of the bug tracker history. How do we move Bugzilla
> >     entries to the Github issue tracker? All references of bug tracker
> >     entries in Buildroot commits would become wrong. Not nice.  
> 
> Right, good catch.
> 
> Very intricate problem ...

Indeed.

So as you can see, moving to another infra is not that simple :-/

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Buildroot, github and nopullrequest.com

[Angelo Compagnucci]

Dear Thomas,

2016-07-16 16:08 GMT+02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Sat, 16 Jul 2016 15:58:35 +0200, Angelo Compagnucci wrote:
>
>> > I just created https://github.com/buildroot/buildroot.github.io for
>> > this purpose, and then realized that we use SSI includes. I think we
>> > should probably move away from SSI includes, to a more modern web-site
>> > generation mechanism, like Pelican (http://blog.getpelican.com/) or
>> > similar.
>>
>> I'm not too familiar with these systems. Usually they are not too
>> flexibles and they tend make difficult to write your own theme for the
>> website. Thay are also blog oriented and not too much website
>> oriented.
>
> Then you indeed don't know such systems very well, because they tend to
> be quite flexible. For example, the https://2016.capitoledulibre.org/
> (french) website is generated by Pelican.

To be honest, my actual income is from a web related job. Probably I'm
not a guru o web design, but I think i developed good tastes.
I had a look at pelican in the past, and not liked too much. Referring
to that website, IMHO it sucks badly! :)

>> >> 2) We have a github account, we should use it as the main repository.
>> >> No other words here.
>> >
>> > Well, there is one *big* issue: e-mail notifications. They are not
>> > available by default, and the only thing that people have been able to
>> > do so far is to have notifications with one e-mail per push (i.e one
>> > e-mail covering potentially multiple commits). This is definitely not
>> > acceptable, and is a show-stopper to moving to github.
>>
>> I didn't realized github is so limited ...
>
> That's a very strong issue with Github. Until this is resolved, no way
> we can switch to Github.

Right.

>
>> > I'm not sure I like giving access to https://nopullrequests.com to my
>> > Google account.
>>
>> You can jump that step, the important is to give the permission to
>> close the PRs (github permission). Obviously is not the most clean
>> solution, but the only viable one.
>
> Not sure what you mean, but:
>
>  * The https certificate of nopullrequests.com is invalid.
>
>  * If I say "No thanks" when it asks me to log in with my Google
>    account, it just redirects me to the Google homepage. Not very
>    useful.

I don't know to much about nopullrequests.com website, I tryied by
myself on GAE and liked quite a bit!

>> I had a look at infradead.org and to it seems way less solid than the
>> infrastructure we have now. On the homepage
>> (http://www.infradead.org/) the author seems to look for a job ...
>
> Well, if you search a bit, the guy in question is David Woodhouse
> (https://www.linkedin.com/in/dwmw2). He has worked at RedHat for 8
> years, and now is at Intel since 8 years. Not sure he is looking for a
> job.
>
> infradead.org is used for the ARM kernel mailing list, which receives
> much more traffic than the Buildroot one. The Git infrastructure of
> infradead is also widely used by kernel people. Grep "infradead.org" in
> the kernel MAINTAINERS file.

Good to know!

>> >  2/ Migration of the bug tracker history. How do we move Bugzilla
>> >     entries to the Github issue tracker? All references of bug tracker
>> >     entries in Buildroot commits would become wrong. Not nice.
>>
>> Right, good catch.
>>
>> Very intricate problem ...
>
> Indeed.
>
> So as you can see, moving to another infra is not that simple :-/

So, what's the with having a better current web infrastructure? I
actually maintain a big infrastructure on aws used by 1M+ users, I
think I can lend a hand!

Sincerely, Angelo

>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



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

[Buildroot] Buildroot, github and nopullrequest.com

[Yann E. MORIN]

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.

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Buildroot, github and nopullrequest.com

[Angelo Compagnucci]

Dear Yann, All

2016-07-16 18:46 GMT+02:00 Yann E. MORIN <yann.morin.1998@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

[Buildroot] Buildroot, github and nopullrequest.com

[Angelo Compagnucci]

Dear Yann,

2016-07-16 18:52 GMT+02:00 Angelo Compagnucci <angelo.compagnucci@gmail.com>:
> Dear Yann, All
>
> 2016-07-16 18:46 GMT+02:00 Yann E. MORIN <yann.morin.1998@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!

I created an account and discovered quite easily how to do that!
Wonderful! Long live to Gitlab!

>
>>
>> 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



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