Re: [Xenomai] [RFC] Service hosting for Xenomai

[Jorge Ramirez <jro@xenomai.org>]

On 11/23/2017 08:39 PM, Jan Kiszka wrote:
> On 2017-11-23 14:18, Jorge Ramirez wrote:
>> On 11/23/2017 01:52 PM, Henning Schild wrote:
>>> Am Thu, 23 Nov 2017 12:42:08 +0100
>>> schrieb Philippe Gerum <rpm@xenomai.org>:
>>>
>>>> On 11/22/2017 09:27 PM, Jan Kiszka wrote:
>>>>> On 2017-11-22 16:32, Philippe Gerum wrote:
>>>>>> Hi Kendall,
>>>>>>
>>>>>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>>>>>> Hi Philippe,
>>>>>>>
>>>>>>> Is there an online bug tracking and feature request database?
>>>>>>> This would be a useful way to distribute work and to sync up
>>>>>>> contributors. I think the kernel uses Bugzilla, and Ubuntu has
>>>>>>> Launchpad. No doubt there are many others.
>>>>>>>
>>>>>>> I'd like to contribute in some way. I've been having a lot of fun
>>>>>>> as a Xenomai user.
>>>>>> We don't have that unfortunately. As suggested by several posters,
>>>>>> moving to a git-based, integrated development framework such as
>>>>>> gitlab or github would bring in that feature, and others we need
>>>>>> too (CI).
>>>>>>
>>>>>> I have no issue moving the project from the current git server at
>>>>>> xenomai.org to any of these environments.
>>>>>>    
>>>>> If it helps the community to grow, I would not refuse such a move.
>>>>> But I would like to raise some concerns about platforms like github
>>>>> or gitlab that we must be aware of:
>>>>>
>>>>> - lacking integration with email-based workflows (while kernel
>>>>>     development tends to be based on that...)
>>>>>
>>>>> - risk of decoupling communities when parts of the discussions
>>>>> happen on tickets or PRs and parts in mailing list threads
>>>>>
>>>>> Therefore, most projects I manage on github and in our internal
>>>>> gitlab have clear policies like "no emails, only tickets and PRs"
>>>>> or "no PRs, only patches on the mailing list". Even just using the
>>>>> issue tracker to keep some to-do list requires discipline to direct
>>>>> discussions consequently to a mailing list if that exists as well
>>>>> (and that usually does not work very well).
>>>>>
>>>>> IOW: we need to be clear in what we want a platform for - and what
>>>>> not.
>>>> Forking the original thread to get input from the list specifically
>>>> regarding the idea of moving GIT services from xenomai.org to a public
>>>> software development platform.
>>>>
>>>> As Jan mentioned, there is more than having GIT underneath, there are
>>>> deep implications on the workflow, and it really depends on what we'd
>>>> want from such platform. If you have any thought, recommendation,
>>>> experience with those platforms in your daily work, it would be great
>>>> to know your views.
>>> Jan is absolutely right here. Before moving to github (or something
>>> alike) you need to set groundrules for how to deal with PRs, issues and
>>> all the stuff that you suddenly gain.
>>>
>>> I think Xenomai could benefit from issue tracking and CI, not sure
>>> whether we need github for that.
>> issue tracking is not something that important IMO.
>> I dont believe this is extensively used by any projects but mainly distros.
>>
>>> The CI they offer is docker-based and
>>> we would likely want something more powerful. But i guess you could
>>> always use docker to remote control AWS or real hardware.
>> yes. there are a number of solutions that in fact do OTA and most of
>> them use Docker to control real hardware.
>> the industry seems to be going in that direction. I think Shippable
>> should server our purpose.
>>
>> for instance, check out this commit:
>> https://github.com/zephyrproject-rtos/zephyr/pull/5134
>>
>> and its shippable output
>> https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/7471/summary/console
>>
> Shippable looks interesting. We are working internally with gitlab-ci
> and for several public projects with Travis. But the free services are
> usually nothing for "serious" workload like kernel builds because they
> either lack powerful builders or have limits on the job length - or both
> which doesn't make it better. For Jailhouse, I worked around that in
> Travis by caching the required kernel build.
>
> Do you know what limits exist in shippable?

sorry no, I havent really looked into it; I mainly saw value in the way 
it integrates within the review process.

>
>>> github sucks at routing mails. My github account is shared between my
>>> work and personal stuff but i do not star/watch any work related
>>> projects because i do not want the notifications in my personal inbox.
>> I agree that it sucks but I dont see why this should be an issue.
>> Just dont rely on github emails (I personally tend to disable them, they
>> are extremely annoying).
>>
>> when I need to find out how any PR is progressing (every other day) I
>> just connect to github.
> It's a personal thing, but web UIs do not scale for me. I'm on way too
> many platforms, and all suck at least a little bit in certain ways. But
> then, when you then need to combine them to keep track, the problem
> becomes serious because email do not work for most of them. Again, a
> personal issue I just happen to share with many kernel hackers.

yes I know; it happens to me as well (ffmpeg, uboot, atf, kernel, AOSP, 
zephyr (first on gerrit, then on github)..they all have slightly 
different channels and processes (and in my case - I guess yours too- a 
myriad of development boards...switching between them all adds to the 
workload)

Having said that, I am questioning the validity of this reasoning, ie 
that we dont do something because it doesnt integrate with why a 
preferred individual way of working.
IMHO there has to be a valid, functional reason other than that.


>
> In the end, the platform we pick depends on the group of developers we
> want to attract. If the majority of our key contributors and maintainers
> become more productive for the project in a specific way, pick that one.

ah ok ,yes I agree with you: are you proposing that the process is 
succinctly defined by a core group of developers and the options then 
presented to the ML for consensus?

> But be careful with choices that cannot be changed again easily.

agree 100% - zephyr did move from gerrit to github and for a few weeks 
it was a PIA to find information.

>
>>> commitment to github etc. is likely to cause sort of a vendor lock-in.
>> ? what do you mean?
>>> I am sure the APIs can be used to extract some information, but will you
>>> get something that you can import into your own gitlab or track later
>>> on? As long as we only use git-hosting and CI from them that would not
>>> be too much of a problem.
>> yeah everything can be done (ie: at linaro we have lava-labs and
>> integrate our own CI loops with Jenkins and real hardware).
>> But I dont believe Xenomai has the dedicated resources for that.
>>
>> BTW at ELCE in Prague, Tgx's daughter presented a very interesting
>> approach [1] to accessing real hardware on CI (using libvirt). Very cool.
>> I think we should use it if in the end we decide to roll our own. But
>> IMO, Shippable should suffice.
>>
>> [1]
>> https://osseu17.sched.com/event/ByYA/continuous-integration-jenkins-libvirt-and-real-hardware-anna-maria-gleixner-manuel-traut-linutronix-gmbh
>>
> FWIW, collaboration projects like Automotive Grade Linux or our Civil
> Infrastructure Platform are significantly investing into LAVA now.

good to know!

>   And
> we also do this here internally. We are not yet at a point where we can
> easily spawn and/or scale out labs, but that time will come. It's an
> industry trend regarding collaborative testing right now, and I'm sure
> we will eventually be able to exploit it for Xenomai as well

100% agreed. everyone is doing this in the industry.

I also liked pretty much Kevin Hilman's kernel-ci [1]; unfortunately he 
doesnt accept patches not upstreamed in his board farm.
Maybe I could talk to Kevin/BayLibre about helping us set a Xenomai-CI 
similar to Kernel-CI?


[1] https://kernelci.org/

> .
>
> But let's focus on CI first. Then maybe easily retrievable test images
> for your manually operated test lab.
>
> Jan
>