|
Replies:
13
-
Last Post:
Nov 15, 2005 1:37 PM
by: michelle
|
Threads:
[
Previous
|
Next
]
|
|
Stephen Hahn
sch@eng.sun.com
|
|
|
|
Development process draft release
Posted:
Nov 7, 2005 12:26 PM
|
|
The development process team has assembled a believed-complete initial
draft, and published it at
http://www.opensolaris.org/os/community/onnv/os_dev_process/
and also as a PDF document at
http://www.opensolaris.org/os/community/onnv/os_dev_process/d-devproc-alpha.pdf
Your comments are welcomed; we hope the document is useful in
defining the engineering dialect in use around software development at
Sun. The process may be biased towards development within the ON
consolidation; I hope contributors from other consolidations will
call out any unreasonable generalizations we may have made.
We plan to redraw all of the diagrams in their entirety for the next
version, so feel free to suggest improvements. My apologies for
the particularly poor rendering in the PDF version.
At this stage, I think a two week review period is appropriate. On
November 21, we can decide whether a new version should be generated,
or whether review should continue.
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen dot hahn at sun dot com http://blogs.sun.com/sch/
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
Posts:
147
From:
Menlo Park, CA
Registered:
5/2/05
|
|
|
|
Re: Development process draft release
Posted:
Nov 11, 2005 1:41 PM
in response to: Stephen Hahn
|
|
I'm surprised that no one else has given you comments yet. Have you posted announcements on the announcements board, code board, etc.?
Here are mine:
Although impossible with the HTML version, it would be nice to have line numbers on all drafts to make reviewing easier. Maybe we just use PDF for drafts?
How are schedules defined? At some point, the CAB or someone has to say "Version x.y.z will come out on yyyy-mm-dd." And what version are we on now? 0.1?
Section 2.2
Instead of saying that features have to be available, serviceable, etc., why not be more explicit? You want features integrated with the Service Manager, Fault Manager, etc.
Section 2.4
Are there ARC reviews? Where is the ARC defined? Who sits on the ARC?
How are people going to test their stuff on all supported target platforms? I think this is a real inhibitor. Linux and FreeBSD don't require this.
How will contracts work? Not very well, I imagine. What if one party disappears? Contracts will be much harder to do outside a single company.
Section 3.1
In the definition of major, you say that major releases occur when any interface might change incompatibly. Later, you say, "...most interfaces controled by someone other than the OpenSolaris community are currently classified as Volatile, but synchronization with major imcompatibilities introduced by those communities is often derred until a Minor release is available." Shouldn't that be a Major release?
And while we're at it, why define a Major release if we're never going to have one? Either redefine all the names so that what you call a Minor release is now a Major release, or name the releases major.minor.micro. I know why we do this inside Sun, but those reasons don't apply outside. Let's fix it while we can.
Section 4.2
You need to define what an RFE is.
Section 4.4
Related to my schedule question at the top, somewhere we'll have to define the points when people can integrate new features and when they can't. For example, just before a release, I imagine people won't be able to integrate huge changing features. There is some period of stablization where only bug fixes are allowed. When will all this be defined?
When are you going to define the C-team, CRT, how they are governed, etc.? In the open world, I'm still struggling with why we need consolidations, C-teams, and CRTs. You just have projects. Each project has a set of maintainers that determine what goes into the project. There must be someone who determines if a project is allowed to integrate, but I'm not convinced that has to be a C-team or CRT. It could just be a maintainer for that bit. For example, maybe there's a TCP/IP maintainer. If you want to make any changes to TCP/IP, you have to clear it with that guy. Think of it as blowing up the C-team across the entire code base. I get a little nervous whenever we talk about adding committees. I worry that may slow things down. I don't want to toss quality out the window, but we have some freedom here. We don't have to do things exactly the same way we've done them inside Sun.
|
|
|
|
|
Posts:
975
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 12, 2005 5:10 AM
in response to: harpster
|
|
On Fri, 2005-11-11 at 13:41, Stephen Harpster wrote:
> When are you going to define the C-team, CRT, how they are governed,
> etc.? In the open world, I'm still struggling with why we need
> consolidations, C-teams, and CRTs. You just have projects.
A consolidation is a tree of source code built as a single unit.
You need someone responsible for ensuring that this unit continues to
function; they need the authority to back out broken changes, etc.,
> For example, maybe there's a TCP/IP maintainer. If you want to make
> any changes to TCP/IP, you have to clear it with that guy. Think of
> it as blowing up the C-team across the entire code base.
when a change to TCP/IP causes NFS to stop working, who gets to decide
whether:
- NFS has to adapt to the change?
- TCP/IP has to back out its change?
- something in the middle?
Changes to "projects" often have non-local impact. The ARCs look for
these impacts at an architectural level, but often these non-local
effects aren't discovered until later -- perhaps even after integration.
IMHO if there isn't someone watching all these integrations and taking a
global view of the system, you'll have a much harder time both
discovering, and then later correcting, severe brokenness.
- Bill
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 12, 2005 8:24 AM
in response to: sommerfe
|
|
Bill Sommerfeld wrote:
> On Fri, 2005-11-11 at 13:41, Stephen Harpster wrote:
>
>>When are you going to define the C-team, CRT, how they are governed,
>>etc.? In the open world, I'm still struggling with why we need
>>consolidations, C-teams, and CRTs. You just have projects.
>
>
> A consolidation is a tree of source code built as a single unit.
...
> IMHO if there isn't someone watching all these integrations and taking a
> global view of the system, you'll have a much harder time both
> discovering, and then later correcting, severe brokenness.
+1 on Bill's comments.
[It is obvious that we *really* need a set of operational definitions.
What are Consolidations, Projects, Communities, C-Teams... and how
exactly do they relate to each other? Without a common understanding
I don't know if I should associate your "just Projects" with my "its
a Consolidation" or with my "its a bugfix effort"...]
It may be, though, that this discussion is really about refactoring
the granularity of the ON consolidation into several smaller, more
focused sub-consolidations. That is, there is a logical hierarchy of
sub-consolidations that, for efficiency (or out of laziness :-) we
have simply stuffed together into the ON wad of stuff:
|== "binutils"
ON ==|
|== kernel ==|
| |== Drivers ==|
| | |== ...
| |
| |== Networking ==|
| | |== TCP ...
| | |== NFS ...
| | |== ...
|== ... |== ...
I believe it *is* important to start working on this refactoring, not
to "blow it up", but to make all of OpenSolaris more accessible and
easier to evolve. If we wish to have a world where there _could_ be a
"TCP project", we need to make it easier to decouple TCP from the rest
of ON in some modular, abstracted way.
IMHO, most of the people in the community will be interested in
development of these sub-components and not in program management.
Based on that intuition, I believe it would be foolish to abandon the
program management/process structure we have today (C-Team, CRT,
gatekeeper...) in the hope that somehow somebody else will pick it up
and maintain the stability and robustness that we
need/expect/require out of Solaris.
-John Plocher
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,710
From:
NZ
Registered:
4/27/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 12, 2005 10:57 AM
in response to: plocher
|
|
John Plocher wrote:
>> IMHO if there isn't someone watching all these integrations and taking a
>> global view of the system, you'll have a much harder time both
>> discovering, and then later correcting, severe brokenness.
>
>
> +1 on Bill's comments.
>
> [It is obvious that we *really* need a set of operational definitions.
> What are Consolidations, Projects, Communities, C-Teams... and how
> exactly do they relate to each other? Without a common understanding
> I don't know if I should associate your "just Projects" with my "its
> a Consolidation" or with my "its a bugfix effort"...]
>
> It may be, though, that this discussion is really about refactoring
> the granularity of the ON consolidation into several smaller, more
> focused sub-consolidations. That is, there is a logical hierarchy of
> sub-consolidations that, for efficiency (or out of laziness :-) we
> have simply stuffed together into the ON wad of stuff:
>
> |== "binutils"
> ON ==|
> |== kernel ==|
> | |== Drivers ==|
> | | |== ...
> | |
> | |== Networking ==|
> | | |== TCP ...
> | | |== NFS ...
> | | |== ...
> |== ... |== ...
>
> I believe it *is* important to start working on this refactoring, not
> to "blow it up", but to make all of OpenSolaris more accessible and
> easier to evolve. If we wish to have a world where there _could_ be a
> "TCP project", we need to make it easier to decouple TCP from the rest
> of ON in some modular, abstracted way.
>
> IMHO, most of the people in the community will be interested in
> development of these sub-components and not in program management.
> Based on that intuition, I believe it would be foolish to abandon the
> program management/process structure we have today (C-Team, CRT,
> gatekeeper...) in the hope that somehow somebody else will pick it up
> and maintain the stability and robustness that we need/expect/require
> out of Solaris.
>
A big +1 from me. I'm sure there are a lot of people who would like to
be able to work on one component without having to replace the kernel.
A good start would be to be able to work stand alone on loadable
components, such as drivers. Can this be done today with the current
consolidation and build process?
Ian
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 12, 2005 8:41 AM
in response to: harpster
|
|
Stephen Harpster wrote:
> And what version are we on now? 0.1?
ON is SunOS 5.11 by definition of the release taxonomy.
Products and distros built on top of ON can be whatever version that
they wish to be (Schillix 0.1, 0.2,...., Solaris 11, ...)
> Section 2.4
> Are there ARC reviews? Where is the ARC defined? Who sits on the ARC?
The ARC stuff is being developed independently - some as part of the
governance proposals, some by the people participating on the
opensolaris-arc forum, as well as a bunch of us internal to Sun who
are (frantically!) trying to push what we have outside the company so
thatr we can have meaningful discussions and evolve a structure that
will be effective and work for us all.
> Contracts will be much harder to do outside a single company.
I tend to agree - I think the bar goes way up and the preference
changes to wanting only public interfaces between components.
Section 3.1
> In the definition of major, you say that major releases occur
> when any interface might change incompatibly. Later, you say,
> "... interfaces ... Volatile,...a Minor release"
> Shouldn't that be a Major release?
It could be as well, but since "we don't do major releases of ON", it
would be kind of pointless :-)
> why define a Major release if we're never going to have one?
Because not all parts of OpenSolaris are the ON consolidaton.
The Desktop/JDS parts of OpenSOlaris do not labor under the same
"anti-major" constraints that ON does; they are much more likely to
include major releases of browsers, desktop office suites and the like.
-John
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
962
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 12, 2005 10:04 PM
in response to: harpster
|
|
Stephen,
> Section 2.2
> Instead of saying that features have to be available, serviceable,
> etc., why not be more explicit? You want features integrated with the
> Service Manager, Fault Manager, etc.
Because this document is meant to lay down the high-level requirements
of OpenSolaris that are not likely to change over time. Technologies
like SMF and FMA are implementations of frameworks that allow
OpenSolaris to have the "available" and "serviceable" attributes, but
it's possible in the future those technologies might be replaced with
something different (however unlikely that seems right now). We did
not want to spell out precise technologies here although I would expect
something like the ARC Twenty Questions[1] to perhaps steer
contributors to the correct answer at any one time.
> Section 2.4
> Are there ARC reviews? Where is the ARC defined? Who sits on the
> ARC?
There are architectural reviews in the abstract process. An
implementation of the process might be the ARC and it's in that
implementation that the structure of the ARC, who sits on it, how it
runs its reviews, etc would be decided.
> How are people going to test their stuff on all supported target
> platforms? I think this is a real inhibitor. Linux and FreeBSD don't
> require this.
The belief is that there will be a test farm set up for OpenSolaris
contributors to test their changes on these platforms. If we don't
require this level of testing, then some platforms are likely going to
stagnate and fall into disrepair and their presence in the project will
likely slow down development across the board.
> How will contracts work? Not very well, I imagine. What if one party
> disappears? Contracts will be much harder to do outside a single
> company.
I believe that's true but personally, I think having some sort of
agreement including contract details, etc that is archived will help
contributors who wish to make a change to an interface and needs to
find out who might be affected by the proposed change. I think it's
not unlike what happens internally when organizations change, and/or
people come and go. Having it documented *might* be of some help.
> Section 4.2
> You need to define what an RFE is.
Yes, we don't seem to define that in the glossary.
> When are you going to define the C-team, CRT, how they are governed,
> etc.? In the open world, I'm still struggling with why we need
> consolidations, C-teams, and CRTs. You just have projects. Each
> project has a set of maintainers that determine what goes into the
> project. There must be someone who determines if a project is allowed
> to integrate, but I'm not convinced that has to be a C-team or CRT. It
> could just be a maintainer for that bit. For example, maybe there's a
> TCP/IP maintainer. If you want to make any changes to TCP/IP, you have
> to clear it with that guy. Think of it as blowing up the C-team across
> the entire code base. I get a little nervous whenever we talk about
> adding committees. I worry that may slow things down. I don't want to
> toss quality out the window, but we have some freedom here. We don't
> have to do things exactly the same way we've done them inside Sun.
I think Bill covered this fairly well but I want to mention something
about how this process was defined and documented. Although clearly
most of the group that came up with this were Sun employees, there was
a conscious attempt to not use the existing Sun/Solaris processes or
Sun's documented Software Development Framework as a basis. Rather, we
started with what OpenSolaris was (see the Fundamentals) and wrote out
the attributes or design principles which made OpenSolaris what it is
(and also, what it was not). From those abstract design principles, we
tried to imagine how someone might contribute changes to that operating
system, whether from a coding point of view, or documentation or even
just participating in designing the process.
We also examined a number of other open-source projects to see how they
handle the various steps of development.
It was from those discussions that the flows came to be. That's why
you don't see ARC listed but rather the need to have changes
architecturally reviewed. There is the notion of a C-Team but in the
abstract, there is a need for someone to verify that a proposed change
is complete, ready to be part of the release bench its headed for and
whether the release branch itself is ready to have it included.
In the end, the process does mirror in many ways the Software
Development Framework but it certainly wasn't intended to do so.
Rather, we tried to make an honest, organic effort to design what sort
of process is necessary to make an operating system with the attributes
that we believe makes OpenSolaris compelling and perhaps different from
other open-source projects.
dsc
[1] For those contributors outside of Sun, the ARC Twenty Questions is
a document that poses a developer a series of questions (now, much more
than 20!) about how their proposed change interfaces with the rest of
the system, and in particular, with key OpenSolaris frameworks. It's
meant to provide an overview of the proposed change.
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
147
From:
Menlo Park, CA
Registered:
5/2/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 14, 2005 8:47 AM
in response to: comay
|
|
>>How are people going to test their stuff on all supported target
>>platforms? I think this is a real inhibitor. Linux and FreeBSD don't
>>require this.
>>
>>
>
>The belief is that there will be a test farm set up for OpenSolaris
>contributors to test their changes on these platforms. If we don't
>require this level of testing, then some platforms are likely going to
>stagnate and fall into disrepair and their presence in the project will
>likely slow down development across the board.
>
>
>
And will this testbed contain PowerPC servers? ARM? Itanium?
I don't want to limit or discourage ports to other architectures simply
because of this requirement and that the test farm doesn't contain said
platform. I also don't want to be in the position of continuously
buying new and exotic hardware for the test farm.
I understand what you're trying to achieve, but there has to be a
compromise.....
--
Stephen Harpster
Director, Open Source Software
Sun Microsystems, Inc.
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,091
From:
CA
Registered:
4/27/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 14, 2005 11:58 AM
in response to: harpster
|
|
On Mon, 14 Nov 2005, Stephen Harpster wrote:
> I don't want to limit or discourage ports to other architectures simply
> because of this requirement and that the test farm doesn't contain said
> platform. I also don't want to be in the position of continuously
> buying new and exotic hardware for the test farm.
Agreed on both counts.
> I understand what you're trying to achieve, but there has to be a
> compromise.....
How about this: stuff must build/work equally well on SPARC and x86
where possible (which should hopefully trap most endian issues), both
of which will presumably be available via the test farm. Other platforms
would be at the developers' discretion.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
215
From:
Scotland
Registered:
9/15/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 14, 2005 12:25 PM
in response to: rich
|
|
On Mon, 14 Nov 2005, Rich Teer wrote:
> How about this: stuff must build/work equally well on SPARC and x86
> where possible (which should hopefully trap most endian issues),
Also: Require -m64 build testing on either US or x86-64 to try flush out
32bit assumptions.
--paulj
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
818
From:
San Francisco CA US
Registered:
3/9/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 14, 2005 1:56 PM
in response to: rich
|
|
On Mon, Nov 14, 2005 at 11:58:58AM -0800, Rich Teer wrote:
> How about this: stuff must build/work equally well on SPARC and x86
> where possible (which should hopefully trap most endian issues), both
> of which will presumably be available via the test farm. Other platforms
> would be at the developers' discretion.
As a veteran of such a second-class port, I will oppose most
vigorously any attempt to allow these ports into a consolidation. If
a port doesn't have enough value to the contributor community to
maintain it as a part of regular development, it shouldn't be
integrated at all. The necessary value might be a business interest
on the part of Sun or another major contributor, or it might be the
personal desire of a large and active group of independent
individuals. The criterion, however, must be a reasonable expectation
that the new architecture will receive first-class treatment from all
contributors, not just its own specialists. The latter model does not
lead to maintainable software and does nothing to foster new ports.
Integration does not help you maintain your port without a global
commitment to its treatment as a first-class entity. If you wish to
maintain a second-class port, you're free to do so as a project; for
all practical purposes, that's what second-class ports end up doing
anyway, because the "official" sources too frequently include changes
that break the unsupported architectures. The end result is a tangled
mess of nonfunctional (and never-used) code in the official sources
and no decrease in the maintenance burden on the port maintainers.
Remember that in the future Sun will not have sole authority to
declare an architecture supported or unsupported, nor will we have
sole obligation to provide test equipment. If you want to putback a
project to port ON to PowerPC,you should arrange for PowerPC testing
resources to be made available rather than assume that Sun will do so
(unless you are Sun and it's your project). Failure to do this would
be seen as an additional increase in the burden you place on other
developers and would make acceptance of your project less likely.
None of this applies to projects that aren't targeting consolidations,
so none of the rules under consideration here can possibly block you
from doing a port or any other kind of radical or far-reaching
project. I do not believe that disallowing the integration into a
consolidation of code which is not expected to be maintained would
form a hindrance to progress.
--
Keith M Wesolowski "Sir, we're surrounded!"
Solaris Kernel Team "Excellent; we can attack in any direction!"
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,091
From:
CA
Registered:
4/27/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 14, 2005 2:50 PM
in response to: wesolows
|
|
On Mon, 14 Nov 2005, Keith M Wesolowski wrote:
> As a veteran of such a second-class port, I will oppose most
> vigorously any attempt to allow these ports into a consolidation. If
Good point, but I think some clarification on my part is in order. I
was reading this part of the thread to mean "any and all changes must
be tested on all platforms". In other words, all changes to generic,
non-platform-specific code, e.g., ls, must be tested on all platforms.
If *that* is the case, I don't know how realistic it is to test on
every platform.
I agree that in principle all ports should be considered "tier 1", but
how does one handle the case of testing a platform outside of the farm
or ones own resources? Do we delay a putback until someone from the
$CPU community says that they've tested the changes and they're OK?
> Remember that in the future Sun will not have sole authority to
> declare an architecture supported or unsupported, nor will we have
> sole obligation to provide test equipment. If you want to putback a
> project to port ON to PowerPC,you should arrange for PowerPC testing
> resources to be made available rather than assume that Sun will do so
> (unless you are Sun and it's your project). Failure to do this would
Agreed.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Development process draft release
Posted:
Nov 14, 2005 12:00 PM
in response to: harpster
|
|
>And will this testbed contain PowerPC servers? ARM? Itanium?
When such ports acquire sufficient mass, then that might need to be
a requirement.
>I don't want to limit or discourage ports to other architectures simply
>because of this requirement and that the test farm doesn't contain said
>platform. I also don't want to be in the position of continuously
>buying new and exotic hardware for the test farm.
>
>I understand what you're trying to achieve, but there has to be a
>compromise.....
Perhaps, in true "grid spirit", we can have people donate systems
to the grid; without the systems to be actually moved some place.
Casper
_______________________________________________
cab-discuss mailing list
cab-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,271
From:
US
Registered:
10/6/05
|
|
|
|
Re: Development process draft release
Posted:
Nov 15, 2005 1:37 PM
in response to: Stephen Hahn
|
|
Hi all,
Great work on this document, it's a lot of information to capture in one piece and you've done a really nice job with it. In general, I think some additional navigation links from the high-level sections to the low-level sections would be useful in the HTML version. Here are my specific comments, mostly related to docs because that is my area of interest:
[MO-0] In chapter2, Fundamentals; Maintainability, add 'man pages, developer documentation, user guides, and online help.' after design documents.
[MO-1] Add a technical writer at the Implementation stage outlined in section: 4 Development Process. This writer would take the draft man pages and working code to begin work on the developer docs. This writer should be a sponsor-level participant.
[MO-2] In this same section, add a technical writer to the Integrate phase. We also need the man page gatekeeper/sponsor here. I think that User Documentation is missing and should be added under Developer Documentation.
[MO-3] Is there a need for another step to maintain what is intergrated? This maintenance step would include addressing anything unforseen that might surface from a project putback, or any needed improvements that are discovered after a project putback. In addition, any requests for additional documentation, versioning, and localization of documentation cycles would be addressed in a maintenance phase. As more information about a project putback is available, this cycle would capture and communicate new info in new languages and formats. This ties into the 'Maintainability' section of the Fundamentals chapter, but it is missing from the flow diagram.
[MO-4] In the design flow diagram, we need to add a cycle for Create/Revise Doc Plan-->Review Doc Plan-->Doc Plan Approved? This should come before Produce Schedule. Also, add a sentence stating that "A documentation plan, however minimal or complex, must be created and approved also."
[MO-5] In the implementation flow diagram, change 'Is documentation needed?' to 'Write Documentation' (box) followed by another box for 'Identify Documentation Reviewers' (technical and editorial). The reviewers might be technical experts in addition to the sponsor and there might be editorial experts other than the technical writing sponsor.
[MO-6] In the integration flow, change 'Review Documentation' to 'Test Documentation' because this phase is a publication/doclint/putback check, not what we normally refer to as a 'review'. We should add some information to the last sentence that follows the TOI piece, stating that 'man pages, updates to developer docs, user guides, and online help are published accordingly for global consumption on a formal documentation site, via the documentation community, or in conjunction with the SunOS man pages or application online help. '
[MO-7] Add a new flow for Maintenance that allows for new improvements to an existing project for security, performance, serviceability, use cases unforseen, new languages, etc. The maintenance flow must have a starting point and I see this as following Integration, but it models the Implementation flow you already have in the document. So, we might have:
Integration
Flow--->Revise Code/Policies-->Pass Unit/Pre-int Tests-->Review Ready?-yes->Integrate Flow
.
.
Revise Docs --> Test Docs
.
.
Request Code Reviewers
.
.
Revise Test Suites
This is an iterative loop that begins and ends with the Integrate Flow and it represents what you describe earlier in the document about how software continues to evolve as additional needs and requirements are discovered. Thoughts?
Thanks,
Michelle Olson
OpenSolaris Doc Community
|
|
|
|
|
