RTEMS developers list (rtems-devel)

[Chris Johns]

On 8/11/11 3:45 PM, Ralf Corsepius wrote:
> 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.
>

This is true and yet I also see the need to not bore or turn away people 
with endless detailed and sometimes heated discussions about technical 
issues. I feel there is no perfect solution and no matter what we 
finally do it will not always work as expected.

>>
>>>
>>>> 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.
>

There is no need to over state your view. You make valid points and that 
is all that is needed. I suspect both use cases exist. It seems this is 
a discussion about the name of the list we need. You know we need a list 
to post patches and have technical discussion about them. Maybe if I 
list the options before us we can decide:

  1. rtems-user, rtems-devel, rtems-bugs, rtems-vc
  2. rtems-user, rtems-patches, rtems-bugs, rtems-vc

The first option groups the discussion and patches in a single place and 
leaves the users list for users, ie its title. The second option needs 
to be explained a little more than the first.

  [ Note, the vc list is being discussed in the other thread ]

>
> 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.

The user only sees the socket interface and termios, not the changes 
inside. This does not discount them wanting to know or being aware. I 
see both side.

>
>>
>>>>>> 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

Agreed. Nothing exciting about patches unless they break your code or 
you think the design is broken and the exchange can become heated. This 
can discourage users who are not confident in open source from posting. 
This is one the reason for the user verses development split. If we have 
a single user and development list then the tone of discussion needs to 
mindful of this.

> to people doing "visionary work" and drive them away.

Are you suggestioning we add "rtems-visionary" as a list ? ;)

Chris