On 05/19/10 04:37 AM, James Carlson wrote:
It'd be nice if some of those broader plans were included somewhere for
review or at least for reference. It is indeed hard for ARC members and
other participants to make any sense out of the materials submitted for
review if there are crucial parts that are not included.
The first order issue is that AI, which has been underway for years,
isn't available for review yet. The network configuration roadmap and
its projects are still seeing significant change.
If AI had been presented to the ARC, I could put together an
overview/umbrella presentation of the network configuration projects
that we are discussing.
But I don't know if that is useful given that there isn't similar
material for AI available to the ARC.
The quality of the review and the eventual product both suffer.
The ARC isn't the only place where things get reviewed, hence I'm not
too concerned about the product quality in the space of network
configuration.
Even given that situation, I still think the project is misguided. A
better approach would be to help the NWAM project do what's needed
rather than building a bypass out of bailing wire. It seems a shame to
miss the opportunity to have these groups working together rather than
at cross-purposes.
I don't understand how speculating on the organizational structure at
Oracle is part of the ARC process.
I'm talking about the projects and the relationships between them, which
are the items under review by the ARC. I neither know nor care about
Oracle's internal structure.
Sorry, but you were referring to there being separate groups (and such
groups consists of people AFAIK) not working together, when in fact that
doesn't match the current organization.
One of the important jobs of the ARC is to make sure that (as much as as
possible) projects are working together in a common direction.
Had your comment been "have you coordinated with the XYZ project" it
would have been different. However, the NWAM project is done apart from
any followup bug fixing, hence it isn't useful to coordinate with that
project.
Moving forward we have a set of work in the area of networking
configuration that spans the range from how servers are typically
configured to the problems NWAM set out to solve. The reason to
structure things that way is exactly to avoid the problems you are
concerned about.
The fact
that there were clear statements in this thread from project team
members saying that they didn't want to have to understand NWAM profiles
certainly makes it appear that project alignment is one of the problems.
http://www.mail-archive.com/[email protected]/msg00616.html
http://www.mail-archive.com/[email protected]/msg00626.html
http://www.mail-archive.com/[email protected]/msg00605.html
I don't see anything on those emails where Mark says or implies that he
doesn't want to have to understand NWAM profiles. Hence I think you owe
Mark an apology.
FWIW There is one organization working on network configuration. That
includes folks that have previously worked on NWAM.
Then let's cut to the chase: have these install configuration bits been
discussed on nwam-discuss?
Not AFAIK. But the NWAM project is done apart from bug fixing hence it
might not be that relevant.
As the 20q document would ask: are the folks
who are working in the NWAM area aware of what this project is doing,
and do they agree with it?
In a previous email I said:
> The NWAM engineers are involved in this and other network
configuration projects.
Perhaps that wasn't sufficiently clear.
Erik
_______________________________________________
opensolaris-arc mailing list
[email protected]
