RTEMS developers list (rtems-devel)

Chris Johns chrisj at rtems.org
Tue Nov 8 04:12:48 UTC 2011

On 8/11/11 2:26 PM, Ralf Corsepius wrote:
> On 11/07/2011 08:13 PM, Gedare Bloom wrote:
>> On Mon, Nov 7, 2011 at 1:14 PM, Ralf
>> Corsepius<ralf.corsepius at rtems.org> wrote:
>>> On 11/06/2011 10:33 PM, Thomas Doerfler (nt) wrote:
>>>> Hash: SHA1
>>>> Hello,
>>>> these are a lot of lists for the (relatively) low traffic ;-) But
>>>> nevertheless splitting the "rtems-users" list into two may make sense,
>>>> simply to allow sorting mail traffic into different categories.
>>> I do not see much sense in a *-devel and a *-users list split.
>>>> What should not happen is that the RTEMS community is split into
>>>> "users" and "developers".
>>> Exactly.
>> I don't think about adding an rtems-devel list as splitting the
>> community. rtems-users is and should remain the "first contact" and
>> primary communication path for all users and should be about helping
>> people get their RTEMS projects working.
> This makes sense in big projects, but doesn't make much sense in small
> projects such as RTEMS, with low traffic mailing lists and small numbers
> of participants.

I do not see this as a traffic volume issue. It is about making RTEMS 
approachable to new and existing users.

>> rtems-devel would be a place
>> for experienced users and developers to discuss and plan development
>> activities, including premature and preliminary design decisions that
>> do not belong on the rtems-users list; We currently have no such
>> place.
> In my view, all such discussions belong on rtems-users, because RTEMS is
> development package addressing developers and is not an end-user package
> who is "klicking app buttons".
> This had been the case ever since RTEMS existed and never had been a
> problem ever.
> rtems-devel offers a solution to a problem, which does not exist.

Our users are developers of their applications and not developers of a 
real-time operating system. BSP, configuration, and tools issues are all 
user type questions and are about using the code base not writing it. 
Also included is API type questions and clarification of documentation. 
These are not related to the development of RTEMS.

>>>> In the past I have seen many people starting
>>>> as "users" step by step became "developers" since they needed new
>>>> functionality for their projects. So we should make sure to encourage
>>>> new users also to register for the "rtems-devel" mailing list.
>>> What we need instead, is an "rtems-patches" list, where prospective
>>> contributors can submit proposals and people with VCS
>>> write-permission can
>>> review contributions.
>> The rtems-devel subsumes such a list and with it we don't need an
>> rtems-patches.
> No. rtems-patches only topic would be reviews and discussing details of
> patches, not general discussions on long term plans and else.

I agree with Gedare. I see rtems-devel being able to manage the function 
of a patch list where patches are submitted, discussed as well any 
design issues around them that may flow. I also see design topics being 
discussed that lead to patches.


More information about the users mailing list