RTEMS developers list (rtems-devel)

[Ralf Corsepius]

On 11/08/2011 05:12 AM, Chris Johns wrote:
> 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:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> 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.
I see this as a traffic issue only.

Splitting lists only makes sense when traffic is too high or if larger 
volumes of contents diverges from a larger user groups interests. 
Neither consideration applies to RTEMS.

>
>>
>>> 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.
A distorted view, IMO.

  Though it's true that probablly only very few people work on RTEMS 
core, probably everybody around here is also working on drivers and on 
BSPs. Only very few work on applications only.

> BSP, configuration, and tools issues are all user type questions and 
> are about using the code base not writing it.
I disagree. BSPs can not be view isolated.

> Also included is API type questions and clarification of documentation.
I disagree even more - APIs are the _key_ to glue together the 
components RTEMS consists of. They can not be viewed isolated.

> These are not related to the development of RTEMS.
I disagree to the maximum for before said reasons.


Much simpler: If something changes about e.g. RTEMS network stack's API. 
the console implementation, these changes need to be reflected to all BSPs.
It's impossilble to treat them independently.

>
>>>>> 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.
Patches are boring to people doing "visionary work" and drive them away.