RFC Authoring and Ratification Process

Developer
Jan 21, 2009 at 5:18 AM
Hey all:

sbalmos mentioned a possible concern about MOSA possibly imposing standards. And though he was very hesitant about endorsing a full-on complaint in that area, and though I myself would not completely allege it either, I am writing to bring up a question a had a week or two ago but didn't take the time to write out an e-mail for.

I think MOSA needs an RFC ratification process. As in, with a voting body, voting yay or nay to approve individual "release" versions of an RFC. Maybe even so much as in, the voting body consisting of equal number of representatives from each MOSA-associated project?

Like, with SharpOS lacking both a maintanable compiler and a compiler maintainer, I can definitely see SharpOS using alot of MOSA's reference implementations. And with Scott Balmos' involvement in MOSA, I'm sure Ensemble will be MOSA compliant as well. But for the moment, we appear to have zero involvement from Cosmos. (Which I don't know the details behind, as I'm sure they've been made aware of MOSA.) And ideally, down the road, we will want involvement from JNode as well.

But a ratification process, consisting (at least partially) of voting from participatory projects, puts weight behind proposed standards.

And don't get me wrong, I'm not saying anything MOSA has at this point needs to whisked away into ratification-land. But it will need to be, perhaps at each milestone release.

-Bruce Markham
aka illuminus
Coordinator
Jan 21, 2009 at 7:12 AM
I understand the concerns sbalmos has (and others may have.) I'm in agreement with a ratification process, I was reluctant to just name a bunch of people. This has to do with personal time, interests and understanding. My idea was that some members of the MOSA community will stand behind an RFC they're interested in and work together to make/finish it. The RFCs I've posted so far are all only drafts whose purpose was to get those interested in them to talk about them in the appropriate discussion topic. A ratification process IMO should try to get those concerned in agreement on a specific RFC, which would declare it final along with a reference implementation of the content of the RFC. I'm not opposed to keeping the RFCs in a draft state for some time with an implementation to gain experience before finalizing the RFC - IMO a better option than to do lots of paper work first.

One more thing regarding the concerns: MOSA itself will not be another competing OS project. Yes, you could take the components and be able to build a MOSA compliant OS without much work, but there'll still be a lot of differentiation in the "distributions" themselves. There's a clear boundary, where my ideas for MOSA stop and ideas for a "distribution" start. MOSA is about choice, ideally providing multiple different implementations of parts of an RFC, like a different number of schedulers or memory managers etc. The distribution picks the parts it'll compile to a kernel, run the tests against it and put its UI, apps etc. on top of it.

Developer
Jan 21, 2009 at 1:19 PM

On Wed, Jan 21, 2009 at 2:12 AM, __grover <notifications@codeplex.com> wrote:

From: __grover

I understand the concerns sbalmos has (and others may have.) I'm in agreement with a ratification process, I was reluctant to just name a bunch of people. This has to do with personal time, interests and understanding. My idea was that some members of the MOSA community will stand behind an RFC they're interested in and work together to make/finish it. The RFCs I've posted so far are all only drafts whose purpose was to get those interested in them to talk about them in the appropriate discussion topic. A ratification process IMO should try to get those concerned in agreement on a specific RFC, which would declare it final along with a reference implementation of the content of the RFC. I'm not opposed to keeping the RFCs in a draft state for some time with an implementation to gain experience before finalizing the RFC - IMO a better option than to do lots of paper work first.

Sure, sure. Definitely.


One more thing regarding the concerns: MOSA itself will not be another competing OS project. Yes, you could take the components and be able to build a MOSA compliant OS without much work, but there'll still be a lot of differentiation in the "distributions" themselves. There's a clear boundary, where my ideas for MOSA stop and ideas for a "distribution" start. MOSA is about choice, ideally providing multiple different implementations of parts of an RFC, like a different number of schedulers or memory managers etc. The distribution picks the parts it'll compile to a kernel, run the tests against it and put its UI, apps etc. on top of it.

I don't think there is any concern there. The problem is, I know of two OS projects, that for various reasons (most of which I am aware of), are not participating in MOSA. I guess, honestly, we need more RFCs to get a better grasp of the granularity that MOSA is trying to achieve. (And when I say that, I have every intent of attempting to draft some RFCs myself, despite the fact that I get a little lost with some of these OS design topics.)

One of the things SBalmos did bring up though, is how the compiler works. Those are the most important bits. Different projects want to do runtime-wiring differently, etc.

I brought up ratification because it was a genuine curiosity of mine, and not directly influenced by the concerns SBalmos brought up. But ratification does help those concerns. And it is definitely something we all need to keep in mind, in the future. (It will become really important as we start to incrementally evolve the MOSA specifications, but we still have to have community support for whatever is already there.)

Developer
Jan 21, 2009 at 3:34 PM
I'll quickly chime in. I don't think this fully covers the idea of
"ratification" that Bruce is referring to. But somewhere in the
catacombs of the current MOSA RFC archives, Jonathan wrote MOSA-RFC-001.
This was basically the "RFC for RFCs", and outlined the various
definitions of "CAN, MUST, SHOULD, etc", along with the necessary
membership voting process. It was his initial goal that the MOSA RFC
process mirror the IETF's RFC process, and more closely the RFC process
of some other software project that the name eludes me at the moment.

It's not up in the wiki, but somewhere in the SVN repo there should be
an RFC folder, with a draft copy of RFC-001, along with the XML template
being used.

--S

illuminus86 wrote:
>
> From: illuminus86
>
>
> On Wed, Jan 21, 2009 at 2:12 AM, __grover <[email removed]
> <mailto:[email removed]>> wrote:
>
> From: __grover
>
> I understand the concerns sbalmos has (and others may have.) I'm
> in agreement with a ratification process, I was reluctant to just
> name a bunch of people. This has to do with personal time,
> interests and understanding. My idea was that some members of the
> MOSA community will stand behind an RFC they're interested in and
> work together to make/finish it. The RFCs I've posted so far are
> all only drafts whose purpose was to get those interested in them
> to talk about them in the appropriate discussion topic. A
> ratification process IMO should try to get those concerned in
> agreement on a specific RFC, which would declare it final along
> with a reference implementation of the content of the RFC. I'm not
> opposed to keeping the RFCs in a draft state for some time with an
> implementation to gain experience before finalizing the RFC - IMO
> a better option than to do lots of paper work first.
>
>
> Sure, sure. Definitely.
>
>
>
> One more thing regarding the concerns: MOSA itself will not be
> another competing OS project. Yes, you could take the components
> and be able to build a MOSA compliant OS without much work, but
> there'll still be a lot of differentiation in the "distributions"
> themselves. There's a clear boundary, where my ideas for MOSA stop
> and ideas for a "distribution" start. MOSA is about choice,
> ideally providing multiple different implementations of parts of
> an RFC, like a different number of schedulers or memory managers
> etc. The distribution picks the parts it'll compile to a kernel,
> run the tests against it and put its UI, apps etc. on top of it.
>
>
> I don't think there is any concern there. The problem is, I know of
> two OS projects, that for various reasons (most of which I am aware
> of), are not participating in MOSA. I guess, honestly, we need more
> RFCs to get a better grasp of the granularity that MOSA is trying to
> achieve. (And when I say that, I have every intent of attempting to
> draft some RFCs myself, despite the fact that I get a little lost with
> some of these OS design topics.)
>
> One of the things SBalmos did bring up though, is how the compiler
> works. Those are the most important bits. Different projects want to
> do runtime-wiring differently, etc.
>
> I brought up ratification because it was a genuine curiosity of mine,
> and not directly influenced by the concerns SBalmos brought up. But
> ratification does /help/ those concerns. And it is definitely
> something we all need to keep in mind, in the future. (It will become
> really important as we start to incrementally evolve the MOSA
> specifications, but we still have to have community support for
> whatever is already there.)
>
> Read the full discussion online
> <http://www.codeplex.com/mosa/Thread/View.aspx?ThreadId=44758&ANCHOR#Post149200>.
>
> To add a post to this discussion, reply to this email
> ([email removed]
> <mailto:[email removed]?subject=%5Bmosa:44758%5D>)
>
> To start a new discussion for this project, email
> [email removed] <mailto:[email removed]>
>
> You are receiving this email because you subscribed to this discussion
> on CodePlex. You can unsubscribe or change your settings
> <http://www.codeplex.com/site/discussions/project/unsubscribe/mosa> on
> codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any
> posts to this discussion will also be available online at codeplex.com
>