GitLab and BuildBot

Christian MAUDERER christian.mauderer at
Fri Feb 10 07:32:14 UTC 2023

Hello Chris,

On 2023-02-09 23:26, Chris Johns wrote:
> On 9/2/2023 6:24 pm, Christian MAUDERER wrote:
>> Hello Chris,
>> On 2023-02-08 23:35, Chris Johns wrote:
>>> On 8/2/2023 8:04 pm, Christian MAUDERER wrote:
>>>> On 2023-02-07 23:37, Chris Johns wrote:
>>>>> On 7/2/2023 9:31 pm, Christian MAUDERER wrote:
>>>>>> On 2023-02-07 07:03, Chris Johns wrote:
>>>>>>> On 30/1/2023 10:12 pm, Christian MAUDERER wrote:
>>>>>> That shouldn't be a pure decision by the one who pays for the work but one
>>>>>> that
>>>>>> is (in the optimal case) discussed and specified in the tickets.
>>>>> I did not know that was happening. I am sorry if you think it is and if I gave
>>>>> you that impression.
>>>> There have been relatively new tickets that changed the status from
>>>> "needs-funding" to "funded" nearly without delay. That was a bit surprising
>>>> for me.
>>>> It seems that the tickets are still updated based on feedback so that is fine
>>>> and it's great that someone funded them. It just would have been nice if there
>>>> would have been some announcement for two or three days like "Someone wants to
>>>> fund the tickets 1, 2 and that part of 4 exactly like they are written now. If
>>>> there are big objections with the direction, please speak up now."
>>> I have never seen EB, your employer, make such an announcement about private
>>> commercial in confidence contracts in this way and I would never expect EB to do
>>> that so I think it is outrageous you think you can ask this here like this. The
>>> funding is a private commercial agreement Amar has and it is no different to the
>>> ones your employer makes. Any questions need to be directed to Amar directly but
>>> I suggest the questions should be along of the lines of what you can fund.
>> Seems that I exaggerated too much. It's a tendency that I have sometimes as an
>> attempt to be descriptive. I'm sorry if that I haven't been more careful in my
>> choice of words.
> Thanks and I understand it is not a natural language for you.
>> Of course, it's not relevant for the list whether it's paid or not and who is
>> paying. It doesn't have to have any special form either.
>> But announcements for changes to the devel list are not unusual in general. For
>> bigger changes it's often done before the change. Sometimes vague but it's at
>> least announced (Example: New build system [1], [2], ...). If someone wants to
>> know more or objects the planned changes he can speak up in these mail threads
>> and concerns can be discussed and in the worst case a change can be rejected
>> entirely.
>> For smaller changes everyone just sends patches to the list that are usually
>> accepted and sometimes rejected if someone objects.
>> For infrastructure changes, a patch review after it is done isn't possible. So
>> these are more the big kind of changes that should be announced with at least a
>> few days time for someone to object or discuss. Tickets are nice but they are
>> not very visible.
> Clearly explaining what is happening is important and if that has not been done
> then I apologise. The planned work on has been split along the lines
> of infrastructure and services. Infrastructure is stuff no one normally cares
> about except Amar and myself with oversight by Joel and Gedare. The list
> includes redundant Cisco firewall updates, base OS updates, movement of jails
> support, the mess of IPMI+Java+Windows, logs, certs and what ever else the
> tickets have. The infrastructure lets us provide the services we run.
> The services we have will run as they have for the last 9 years. The upgraded
> infrastructure will let add new services such as CI and that is part of the
> selection process you have kindly participated in.

Thanks for the explanation.

>>> This list is open and public for the project and its community and I will not
>>> tolerant any commercial activity of any type.
>> Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets already
>> had something similar in the comments, so I didn't think that someone would
>> object as long as it is an anonymous "Someone wants to fund ..." and not
>> "Company X wants to fund ...".
> Understood. My comment was a reminder to everyone and not specifically you. This
> discussion is archived so making sure what we are talking about is clear is
> important.
>>> Regarding the tickets, there are many cases over the years of those providing
>>> services performing services internally, raising tickets and committing changes.
>>> I see no issue here and I am fine with that continuing to happen.
>>> Finally, my understanding of the funded tickets is most of the work is to
>>> rebuild the servers to be current and capable of running modern CI systems, what
>>> ever that ends up being.
>> Maintenance tasks that keep the systems running are fine without an
>> announcement. These are a lot of great work that happens behind the scenes.
> The maintenance has been happening for nearly 9 years unfunded. A lot of
> organisations and individuals have created a lot of systems running RTEMS and
> serviced a lot of clients in that time accessing this system. Lets not lose
> sight of that :)
>> But
>> these tasks don't change how a user can access the system. It's great if someone
>> decides to make that work visible too so that everyone can at least say a "thank
>> you", but it's not necessary.
> Access means different things to different people. Amar and I see all levels in
> the system and access to say the firewalls is restricted for good reason.

Of course. I meant "access" in the sense of a user of the services. 
Access to the infrastructure is something completely different and of 
course that has to be restricted to the people maintaining the 

>> For tasks that change something fundamental, some public review time would be
>> nice at least a few days before the work starts. Like said above: I would see
>> that similar to review time for every patch that is more or less a suggestion to
>> change something.
> The areas that matter to the users and I suspect you are open for review and
> discussion.


> I see CI and gitlab as an important step for RTEMS not only for the ability to
> make patch management easier and modern but gitlab can have admins who do not
> need jail or base OS access, each repo can have maintainers and helps spread the
> load and includes more people in the project admin side of things.
> Patch management does mean we will need to discuss how we run t? For example
> self approval, voting, common rules for all repos, etc.

These processes would be good to discuss because it will change (for 
example) the currently established "Blanket Write Privileges" vs. "Write 
After Approval". But I think there is still a bit of time for that.

> And lets not underestimate the work that will happen in the background to bed a
> system like gitlab in. It will be busy and there will be issues. I can only
> appeal to everyone that the effort and intentions are for the good of the
> project. No individual or company is gaining any benefit over another.
>> I haven't seen that announcement and review time for the tickets that are
>> already funded.
> Review time is an awkward topic. Do we apply review periods for the
> admin services and not to the posted patches for or related tickets? I
>   prefer we avoid making rules like this so close to moving to a patch review
> system and how we run that.

What I tried to express with that is the following: From the perspective 
of a user of the services it is nice if there is some time to give 
feedback before something that changes the user experience is 
implemented. Of course that doesn't always work. So I agree: Fixed rules 
most likely wouldn't be a good idea.

>> Maybe I missed it and if that is the case it's fully my fault
>> and I'm sorry that I even started the discussion. On the other hand all
>> currently funded tickets fall into the category "necessary maintenance task" so
>> I clearly overreacted to even mention it.
> Maybe or it has not been explained? You are right the ones that are funded make
> a platform we can use to provide new services.

Thanks for the confirmation.

>> Regarding the commercial aspect: Of course an announcement doesn't have to
>> happen before a contract is closed - that is something between the two companies
>> or individuals that close the contract. But like you said multiple times
>> yourself: It's not a contract that the RTEMS project closes but one between two
>> unrelated legal entities. So it's still possible that a community members might
>> object and in the worst case block the change.
> That is true but the need for the work to be done has been a constant topic with
> Joel and Gedare. The timing was tight and things happened back to back but it
> was just how it worked out. Given we are limited in what can be discussed with
> the infrastructure I doubt it would have mattered. Nothing has changed, what
> exists is just being updated and upgraded and some things fixed like log
> management and automatic cert updates which have been a constant source of
> downtime for us. But your point is noted.

I mentally didn't separate what you called infrastructure and services 
above. At the moment everything funded is necessary infrastructure work 
so most of what I asked earlier (like announcements or discussions) most 
likely is not relevant.

>> Just to make that clear again: Except for some details (that we are currently
>> discussing in various mail threads) I'm really happy with what is happening so
>> let's hope that no one objects the new infrastructure.
> Thanks and it is great to get the feedback. We normally only ever hear from
> people when it does not work :)

I hope that I'm not too annoying. I think I started some quite long 

Best regards


> Chris

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
email:  christian.mauderer at
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:

More information about the devel mailing list