
I'd actually be interested in hearing about problems with GitHub and processes long before the summit. Maybe they can even be fixed by then.
Is there anything specific that should be improved?
I suppose I don't have any major gripes with github. It is actually quite impressive with CI. I haven’t actually gathered all my thoughts yet on the subject. I think gerrit is a better review tool for open source, because it is much easier to compare various rebases, but the convenience of having reviews, issue tracking, and the code all in a single location really makes up for less than perfect reviewing. Which is the same reason we use gitlab internally instead of gerrit. Process issues: - Reviews tend to go stale. My guess is that this is mostly due to lack of resources. Hopefully the dedicated reviewer role can help with this. - Some of the reviews that are stale are in our corner as well. We are also resource constrained. - Hard to reach a conclusion on RFCs. Maybe this is on us for not continuing the discussion, but the conclusion of https://sel4.atlassian.net/browse/RFC-9 was that we(the community, the foundation?) should think through more implementation options. Changes like this, which are needed to support basic customer features, sitting around for a while results in us needing to push our patches along as the code updates over time. This is also made harder by the multiple repositories. I am not sure there is a great solution for this. Some thoughts are accepting changes like these with the knowledge that they will get incremental improvements. Alternatively, maybe there could be an experimental or staging branch that periodically gets updated. Thanks, Robbie -----Original Message----- From: Gerwin Klein <kleing@unsw.edu.au> Sent: Tuesday, April 26, 2022 9:13 PM To: ihor@kry10.com Cc: Heider, Axel <axel.heider@hensoldt.net>; summit-pc@sel4.systems; Robert VanVossen <Robert.VanVossen@dornerworks.com> Subject: Re: [Summit-pc] seL4 Summit Panels CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I'd actually be interested in hearing about problems with GitHub and processes long before the summit. Maybe they can even be fixed by then. Is there anything specific that should be improved? Cheers, Gerwin
On 27 Apr 2022, at 10:53, Ihor Kuz <ihor@kry10.com> wrote:
I agree that the specific topic may be too narrow for a panel, but would be a great presentation (structured to encourage discussion).
Another option would be to broaden the scope and make it a panel - e.g. to have a panel about contribution in general.
Ihor.
On 26 Apr 2022, at 03:18, Heider, Axel <axel.heider@hensoldt.net> wrote:
Robbie,
I was thinking about writing an abstract for a presentation on DornerWorks’ experience with mainlining. Focusing on the good pieces, the challenges (which come from our customers, our limited funds, our process, from github, and from the foundation processes), and some thoughts on how to improve. My colleagues thought it could be better as a panel so that we could get perspectives from others in the community, as well as the foundation. I wholly agree with them. So I was wondering if others thought a panel or two would be a good idea. If so, should it still be submitted as an abstract?
My opinion is, that a presentation would be a good input to kick off an open discussion on the topic. But I have some doubts that a panel discussion for a general audience with a few selected speakers is really a way forward. It would take a few more presentations how others do it and then see what could be adapted. Seems more a topic for a break-out session or a working group with dedicated resources that can improve things.
Axel _______________________________________________ Summit-pc mailing list -- summit-pc@sel4.systems To unsubscribe send an email to summit-pc-leave@sel4.systems
_______________________________________________ Summit-pc mailing list -- summit-pc@sel4.systems To unsubscribe send an email to summit-pc-leave@sel4.systems