Hi Stephen,
Just a few editorial comments from me.
> 2.1. Project Description:
This sentence seems confusing to me.
> At a minimum, it is intended to combine in a more usable
> fashion the functionality of the current packaging and
> patching utilities used with the historical Solaris releases.
If I paraphrase this with the sentence below, does it retain the
intended meaning?
The pkg(5) project will subsume the functionality of the of the
packaging and patching utilities included in historical Solaris
releases. A primary goal for this project is to improve and
extend the usability and functionality of our packaging system.
> 2.2. Risks and Assumptions:
>
> It is assumed that the legacy packaging system functionality can
> be preserved to support compatibility of existing packages. It
> is further assumed that, if migration and compatibility
> practices are made available, that the provision of a new
> packaging mechanism will be followed by adoption.
The "that" that follows the "made available," is unnecessary. The
statement about migration and compatibility is parenthetical.
> It is asserted that the refactoring and renaming of the existing
> package graph is not achievable with reasonable cost and
> duration with the existing packaging/patching/installation
> software.
It's probably redundant to write that we're asserting something when the
document is, at least in part, our technical opinion. What do you think
about the following?
An exorbitant amount of time and money would be required to
refactor and rename the current package graph with our existing
tools.
> It is assumed that compatibility with the existing
> graph can be preserved, to support the earlier assumption on
> preserving legacy package operations.
"assumption on" sounds funny to me. What about "assumption upon" or
"assumption about?"
> It is assumed that binary software delivery is the preferred
> mechanism, over source build-based delivery, for a significant
> majority of the deployment and development needs associated with
> the operating system.
When I first read this, I thought it was a run-on sentence. It isn't
but the parenthetical statement caused a miscue in my reading. Also, is
a "significant majority" redundant? A possible correction:
For the majority of the operating system's development and
deployment needs, binary software delivery is preferred over
source-based build delivery.
or:
The delivery of binary software is preferred over the use of a
source build-based approach. A significant portion of the
deployment and development needs of the operating system will be
satisfied by the delivery of software in binary format.
> 3.1. Problem Area:
>
> Deficits in the current packaging, patching, and installation
> tool set affect potentially all parties interacting with the
> historical Solaris releases and their successors.
Should this be, "historical Solaris releases and its successors," since
we're talking about Solaris releases and not people?
> An additional cost, beyond those associated with a specific
> operating system, is the absence of a portable and efficient
> cross-platform software delivery system for cross-platform (or
> minimally platform-dependent) software.
This sentence seems like it has singular/plural agreement issues. I
could just be grammatically imparied, though. What do you think about
writing it this way:
The absence of a portable and efficient cross-platform software
delivery system places additional costs upon teams that must
deliver software for multiple platforms. (i.e. Java and
StarOffice)
> 3.2. Market/Requester:
>
> Distribution providers and software content providers utilizing
> the legacy packaging system have requested substantial changes
> to achieve greater control over maintenance costs and to
> increase development efficiencies.
This is a hefty sentence. Could we re-write this as:
Distribution and software content providers have requested
substantial changes to the legacy packaging system. The
requested changes focus on reducing maintenance costs and
increasing development efficiencies.
> 3.5. Opportunity Window/Exposure:
>
> The project team asserts that, for Solaris to remain competitive
> in terms of software delivery functionality, Solaris 10 should
> be the last Minor release to not offer a packaging system that
> meets or exceeds the minimal needs stated in 3.1 and 3.2.
I don't think that the statement abotu Solaris's competitiveness was
intended to be parenthetical. How about:
In order for Solaris to remain competitive in software delivery
functionality, Solaris 10 should be the last Minor release
with a packaging system that fails to meet the needs stated in
3.1 and 3.2
> 3.6. How will you know when you are done?:
>
> Finally, ease of use (or familiarity) must match or exceed
> that of other leading packaging systems.
At what point in the process do we actually set out the features in
other packaging systems that we intend to match? It seems like we're
opening ourselves up to an argument about whether we're done or not if
we're not specific.
> 4.1. Details:
>
> Additionally, the project defines a client-server publication
> mechanism, in which the client offers up transactions on
> packages, and the server evaluates those transactions for
> completeness and/or safety prior to making them available for
> retrieval by clients.
I think this can be broken into a few sentences. What do you think
about:
The project defines a client-server publication mechanism. The
publication client offers up transactions on packages. The
server evaluates transactions from the publication client.
Transations that are deemed to be complete and/or safe by the
server are then made available to the retrieval client.
In general, this looks great. Thanks for taking the time to write
this stuff down.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
