RTEMS Developers List is available.

[Ralf Corsepius]

On 12/05/2011 07:32 PM, Thomas Doerfler wrote:
> Am 05.12.2011 18:41, schrieb Ralf Corsepius:
>> On 12/05/2011 04:23 PM, Joel Sherrill wrote:
>>> On 12/03/2011 03:54 PM, Chris Johns wrote:
>>>> As others have noted the discussion happened in public.
>> There was no consensus.
>
> After the first proposal, there where some complaints (also from my
> side). The concept of the mailing lists was refined then and some
> details concerning the usage were laid out. Then there was no further
> traffic concerning the new mailing lists.
This matches with my memory - I would have expected Chris to have 
contacted the SC to let it decide on this controversal topic.

This did not happen - Instead he went ahead and implemented facts.

> Maybe we need a formal decision process?
Yes.

> I don't think it should be a
> "all agree or nothing changes" process.
Certainly not ... but it also must not be a "I have the powers, so I do 
it" process (THE problem in RTEMS) nor a "publicity contest" (A problem 
e.g. Fedora and Ubuntu suffer from).

> Any idea how this is handled in
> other OS projects?
Better lead projects have bodies who decide upon what to do (e.g. 
steering committees).

I had presumed this was amongst the RTEMS SC's jobs - Apparently I was 
wrong.

>>>> I see no reason
>>>> for the SC being involved.
>>> Agreed.
>> Disagreed. What you did was to circumvent the decision process and a
>> case of abuse of the powers you have been granted.
>
> Again: which process?
Strategically important decisions, such as implementing a project's 
lists do not belong into the hands of single individuals.

They belong into the hands of the people who are leading and guiding a 
project. In case of RTEMS in my understanding this is the RTEMS SC.

> Where is the decision process for the RTEMS SC
> defined?
Nowhere.

That said, IMO, the RTEMS SC needs to be strengthened or it shall be 
formally shut down and all former RTEMS-SC discussions be performed in 
public.

>>>>> A step, I vehemently disagree withand a step I vehemently disagree with
>>>>> how it was done.
>>>> The whole process has taken place in public and I assumed anyone on the
>>>> SC would be prepared to make any comments publicly. It is just a mailing
>>>> list we are discussing.
>>>>
>>>> I started the process of a new list for a few reasons. The most
>>>> important is the need to provide a mailing list for review of patches
>>>> before committing. This became important because you requested, and it
>>>> was agreed, that Gedare be given commit after review, something this
>>>> project has never had. We have no defined procedure or protocol for
>>>> commit access in this way. No one stepped up to resolve this situation
>>>> so I started this process. Without this happening Gedare was given
>>>> something he did not know how to use. We should being doing everything
>>>> we can to welcome and encourage new committers to RTEMS.
>>> This also follows the practice of other large free software projects.
>>> Many projects have a developer, patches, and user help list.
>>
>> Pardon? No sane project maps bugzilla and commits to a devel list,
>> because bugreports and commit lists annoy developers.
>
> Hm, at least now RTEMS doesn't do this either. bugzilla and version
> control has separate lists.

 From Chris's initial mail:
"I will also change the rtems-bugs and rtems-vc list to read only. The 
reply-to address will be set to the developers list."

<further comments disclosed>

Ralf