Darren Reed writes:
> What I was looking for (or hoping for) was an indication of what
> other documents were known to be desired for developers to
> make use of in the OpenSolaris community. It would seem that
> this is currently an empty set so there's no point belabouring
> the point. As we become aware of them or the need for them,
> they can be added to this project as additional tasks.
It's not an empty set. Detailed developer's guides ("how to write
your software to work in OpenSolaris" and not "how we wrote this") are
likely needed for at least:
- iphooks
- squeues/FE
- sockfs
- PEF
It's possible that there are others. The issue likely isn't just with
kernel interfaces. I'd expect that future projects such as casting
the interface configuration into SMF would result in a new set of
internal integration issues that need to be documented somewhere.
> I'm not convinced that the delivery of templates is orthogonal to
> the project "Network Documentation." So long as we write all
> of the documentation in house, it is, but if we plan to ever accept
> contributions from outside, it will be of benefit. It's probably a
> separate task in itself. That said, it isn't of immediate concern
> for this project.
Like the system requirements issue ("shall we force all projects to
deliver documentation like this as a condition of integration?"), I
think it'd be great if this project chose to deliver templates and
other materials that will be helpful for future work.
I don't at all agree that those templates are specially required for
outside contributors (are they somehow less capable authors than we?),
but I do think they'd be good to have nonetheless. If you feel it's
important enough and are willing to contribute those bits, let me
know, and I'll add your name to the initial project team list.
As it stands, I don't think anyone on the existing project team has
the interest of doing those things, but perhaps it'd be worth
discussing the issue on the project team mailing list ... once we have
one.
> So far as requiring new projects to deliver documentation that
> becomes part of this project - that's a matter for the networking
> community as a whole to decide and outside the scope of this
> project. Any clues on how we go about making that sort of
> resolution?
I agree it's a community decision.
The constitution (Article VIII) provides pretty clear guidance on how
to do this. This would be subject to a majority vote, so the process
would be:
- start a new thread with the proposed requirements to be
adopted.
- collect at least 3 +1 votes and more +1 than -1 votes
- terminate no earlier than 72 hours later
- publish the new requirement somewhere on our community web
page
There are some fiddling details about how we'd actually get the
mechanics to work (do C-teams pay attention to Community Groups?), but
those are very likely to be solvable problems.
> Anyway, if I read the proposal correctly, the delivery of the GLDv3
> documenation doesn't mark the end of the project - which is the
> biggest worry I have/had and I think this is shared with others.
Correct; it's just the first named task.
> As long as this is the start of a project that continues into the future,
> I'm happy to give it +1.
OK; thanks.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
