Re: [osol-discuss] Internationalization
* Bruno Filipe Marques <[EMAIL PROTECTED]> [2005-07-26 07:03]: > Hello to all > I would like to contribute to OpenSolaris Development. > Since i'm from Portugal, and make my PhD Research in IP Network Management, > working with Sparc Solaris, Linux and Windows, i feel like need to have a > I18N in Potuguese pt_PT language. > So, what do i need to do and what steps should i make. Visit the I18N and L10N community: http://www.opensolaris.org/os/community/int_localization/ Their main list is [EMAIL PROTECTED] Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] The teamware effect
* Roy T. Fielding <[EMAIL PROTECTED]> [2005-07-29 11:44]: > Visibility is an essential aspect to collaboration and equal > participation. Whether or not you believe that a group of developers in the larger OpenSolaris universe should have a choice about whether their ongoing work should be public or not, I think that it's peculiar to assign blame for the presence or absence of visibility to the choice of SCM tools. Project visibility is increased through regular use of many forms of online communications mechanisms. Project teams that propose large or fundamental changes involve more communication, more discussions with architecture review, and more coordination with other project teams or with experts in affected areas. Smaller sets of changes can successfully integrate with only code review and integration approval. Intermediate changes might need a very brief architectural check, or specific consultation with an interested group. Communication in large projects can involve any or all of: public source code repositories (in a company wide directory), web sites, multiple mail aliases, and, in some cases, IRC channels. I suspect if you polled project leads today, they would speculate about syndicating both their web site updates and their repository integrations. Of course, meetings and mail exchanges with architecture review and release teams, in addition to their primary purpose, also informally disseminate knowledge of the project to interested parties within the constituencies of those boards. > Interestingly, this teamware effect is also found in Linux > development, which in spite of its open source nature has never > been a collaborative effort in any real sense. In Linux, > individuals build trees on their own and make changes in their > own projects. When done, the hardy folks among them enter the > process of convincing one of the benevolent dictators to accept > and integrate the changes (as they see fit) with their next > revision. The "community" only participates in the sense that > code eventually shows up in the unstable release path. [elision] > Folks here keep using Linux as a model as if it were the paradigm > of open source development. I think you should be looking more > closely at the FreeBSD and Apache styles of development, which > have successfully integrated strong peer review and stable > interface revisions in the same manner as Sun but *with* true > community collaboration. I think you will find that such communities > closely match the values held by Sun engineering and yet are able > to collaborate as equals. I don't believe this is an "either/or" choice for this community, both in the sense that a particular SCM choice would lead to one model or the other, or that these are the only two viable community models. The internal process currently generates a product from the contributions of over 800 committers per release to ON alone,* with disjoint architecture review, test development, integration, and software release. The architectural and release acceptance processes remain objective in general, despite large (and--I should know-- controversial) changes being proposed and completed. Incomplete proposals are given guidance and, when appropriate, connected to teams working in related areas. All process interactions are documented, and can be used as models for future work. If we recharacterized the eligibility and manner of selection for the seats on the technical side, and replaced the business input side with a community driven equivalent, wouldn't we have a reasonable third model for pursuing scalable community development, with a documented process? (Has there been a discussion of where the current process, with its entities restaffed by community selection, and without reference to specific tools choices, has identifiable shortcomings with respect to collaborative development?) I suppose an alternative way to look at it is, "could a large group really produce a complex product *without* a reasonably effective form of collaboration?" - Stephen * This count undercounts individuals as team commitments are integrated by a single team member. Furthermore, these committers come from different organizations and have different aims that are somehow reconciled. Beyond that, there are other bodies of code and documentation with their own overlapping sets of committers. -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] New community proposal: Approachability
One of the areas we've been working on after Solaris 10 has been labelled "approachability"--a rather vague term for "eliminating both annoying and substantial gaps in the operating system". Areas we've been investigating include simplifying complex operations, like rich networking configurations and service failure diagnosis, but also include irritations for administrators, developers, and users new to Solaris. Obviously there is a host of irritations: the discussion of command line editing and history for sh(1), the legitimate default settings for root's shell, the difficulty of configuring certain basic network settings have all come up on opensolaris.org mailing lists in the past week. What we're trying to do in Approachability is refine OpenSolaris development to be free of itchy seams, like these: - why is there not a default NTP client configuration that works? - why do I have to reset every network setting to change one safely? - why is every network service on when I install the system? - why do I have to change my PATH to find gcc and other useful developer commands? - why is this popular command/function/capability missing? The list, while not endless, is longer than any of us would like; what's important to note is that most, if not all, of these could have been avoided up front *if* a larger discussion of "typical usage" had occurred in the design discussions around each of these features. One thing to note: Approachability deficits are often also deficits in security, usability, distribution completeness, or just basic functionality. Once made, they almost always save people time, but they might require balancing against other technical communities' goals. I'd like to get this discussion out and onto opensolaris.org, so that inputs, fixes, and new ideas come from the larger set of people who care about OpenSolaris adoption. If you are interested, please let me know, or just join in. Thus: --- This message proposes the creation of an Approachability community for OpenSolaris. Please discuss. --- Thanks Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New community proposal: Approachability
* Glynn Foster <[EMAIL PROTECTED]> [2005-08-02 17:59]: > Hey, > > >I'd like to get this discussion out and onto opensolaris.org, so that > >inputs, fixes, and new ideas come from the larger set of people who > >care about OpenSolaris adoption. If you are interested, please let > >me know, or just join in. Thus: > > Sounds fantastic to me. Is this the grown up name for the internal KISS > [1] group out of curiosity? > > [1] Keep it simple, Solaris It's the same idea and the same set of folks; I liked calling resource management "predictability engineering", so I've been partial to approachability engineering as the discipline encompassing this set of work. Plus KISO doesn't have nearly the same punch. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New community proposal: Approachability
* Tao Chen <[EMAIL PROTECTED]> [2005-08-02 19:16]: > On 8/2/05, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > One of the areas we've been working on after Solaris 10 has been > > labelled "approachability"--a rather vague term for "eliminating > > both annoying and substantial gaps in the operating system". Areas > > we've been investigating include simplifying complex operations, like > > rich networking configurations and service failure diagnosis, but > > also include irritations for administrators, developers, and users > > new to Solaris. > > > Sounds like a perfect place for less-experienced Solaris users to share our > growing pains. > > [Example of approachability issues with install server set up elided.] > > Is this a good example of what can be posted to "approachability" list? Yes. Installation is seen as one of the components most in need of approachability reengineering, and is (not that you need care) a group within the larger Approachability/KISS organization within the Solaris group. For the purposes of the community, however, your next point is critical: > I may be wrong, maybe there's a good techincal reason why it can't be > automated. However, as an user and someone who wants to recommend the > OS to others, I'd like to have the opportunity to raise my concern, > even if I already get the job done, but want to see the job becoming > easier for others in the future. Standard operations that do not respect the operator's time are not approachable. That is, designing such that typical operations are automatic or otherwise economic is a key aspect of approachability. > I feel this kind of 'complain' may not be well-received by the > opensolaris-discuss list, where 'more important' issues are discussed, > so maybe it's a good idea to have a separate list. > > Hope I am not too off from the idea of your proposal. > > Oh BTW, how do you define the difference between "approachability" and > "usability"? Depending on one's point of view, each might be expressible as a subset of the other. I think that at this point in OpenSolaris, approachability is about eliminating the need for configuration in the majority of cases. Services, although disabled for security purposes, come with effective default configurations if they are enabled.* Configuration, where needed, is keyed off networked sources where available, or generated from a guided set of questions--but as few as possible. If you like, approachability can be considered simpler than usability: it's about being complete in delivering the default solution one normally constructs about a particular feature. Usability is often about identifying necessary concepts and making them consistent across a range of features: that's some combination of synthesis and art. - Stephen * In case you ever wondered why smf(5) separated enabled/disabled intent from configuration presence/absence, here's one of the abstract reasons. -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New community proposal: Approachability
* Al Hopper <[EMAIL PROTECTED]> [2005-08-02 23:21]: > On Tue, 2 Aug 2005, Stephen Hahn wrote: > > >This message proposes the creation of an Approachability community > >for OpenSolaris. Please discuss. > > +1 > > But you would probably need a definition of what is the difference between: > > 1) RFE > 2) something does not behave as expected, but does behave per the docs/man > pages > 3) default configs > > and the points that you already mentioned: > > a) too time consuming to set up > b) too difficult to setup > c) inconsistant with a similar feature (set) elsewhere in the Operating > System > d) nuisance tasks (I always have to do xyz *every* time I setup a new box > or a new zone etc) > > For example the case listed earlier for most of the PXE setup being done > automatically: is that an Approachability item or an RFE? Is there an easy > way for a user to determine it accurately? > > If someone asked for a PXE boot setup "sanity" checker would that go > to the RFE list or the proposed Approachability list. In either case it > would certainly be a useful tool and could catch many of those silly typos > and blatantly incorrect and inconsistant configs that take hours to trouble > shoot. Using the idea of install server checking command: that would be an RFE for the Installation community to prioritize and pursue, but that the Approachability community would passionately pester them to make. In some cases, an Approachability community member might start a prototype as a project, offer a proposed interface, or just identify that there is a disconnect between the implementation and the believed common case. (Sun community members would be expected to dedicate time to tracking, labelling, and understanding the impact of Approachability deficits, and attempt to intercept Sun contributors before they introduced new deficits, in addition to participating in the development of community consensus about projects and priorities.) That is, like Availability, Approachability is something that all projects need to consider, although their technical aims may require very different expertise. An interesting aspect for the replacement of the notion of a steering committee in the new model might be that the -ity communities provide feedback to the technical communities on how distant the technology is from having the ideal quality a particular -ity community is. As in, "we're focusing on Project A because it impacts our Availability, but we'll get to Project B, and its benefits for Approachability, right after that...". Of course, one could argue that architecture review should already encompass and balance all of the -ities... - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New community proposal: Approachability
With all these +1's flying about, I thought I should ask if CAB member cares to spare a second +1 for Approachability? (We're interested in making things "just work right" on all kinds of platforms.) Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What is a "community"?
* John Plocher <[EMAIL PROTECTED]> [2005-08-10 09:39]:
> Roy T. Fielding wrote:
> >At some point we need to make a distinction between creating
> >mailing lists/forums and creating self-governing groups responsible
> >for building products. Which one falls under the name "community"?
>
> +1
>
> IMHO, IAC!
>
> I thought I had a handle on this community thing when we launched the
> OpenSolaris "ON Community" - a group of people involved with the
> "source tree formerly known as the Solaris Kernel Consolidation".
>
> The proto-governance proposals floating around all made sense to me
> when used in that context, though it was easy to imagine other equally
> as useful interpretations. My "sanity test" was whether the following
> phrase rang true:
>
> The community consists of the movers and shakers (aka maintainers)
> who are steering, architecting, designing, implementing and
> sustaining
> the codebase in question.
>
> This implies (to me) that a community is something bigger than a single
> bugfix, yet smaller than an entire distro. My experience with things at
> Sun leads me to associate "a community" with the abstraction we call a
> "consolidation", and not with smaller "projects" or larger "products".
>
> NB: The jury is still out as to whether or not this association is valid.
> It could be that the thing we currently have is "too big" to be a single
> community, and needs to be refactored into smaller abstractions. Some
> possibilities that come to mind are splitting out drivers, filesystems,
> posix/gnu utils and the core kernel/networking stacks - each would have
> its own community driving its growth, independent of the others. Or not.
>
> Then came the explosion of mailing lists and forums on the web site. They
> were also called communities, yet not all were focused on things that were
> directly tied into "identifiable pieces of code".
I had been reading the governance draft such that communities had
a precise membership and one or more formal ways of achieving
consensus. Like John, I had matched up communities with a number of
the bodies in the internal process: some communities were
consolidations, some were more like steering committees ("doing X is
important"), and some were technical programs.
It does seem like there is a need to provide some mechanism supporting
group collaboration that is more ad hoc than the community. Let's
call this a "project". A project could have a mailing list and a home
page and, eventually, a source code repository of some kind. Project
initiation and membership do not necessarily connect with any of the
communities, but a community could choose to endorse one or more
projects (which would show projects with some consensus support).
For instance, I would expect smf would be turned into a project, and
that it would gain the endorsement of the Nevada and (I hope) the
Approachability communities.
If opensolaris offered projects with mailing lists (and we revisited
some of the current communities and converted them to projects), would
that support the specialized conversations people want to have, while
preserving the communities as the decision-making bodies over larger
products and aspects?
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED] http://blogs.sun.com/sch/
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New community proposal: Approachability
* Simon Phipps <[EMAIL PROTECTED]> [2005-08-16 18:02]: > On Aug 10, 2005, at 01:29, Stephen Hahn wrote: > > > > With all these +1's flying about, I thought I should ask if CAB > > member cares to spare a second +1 for Approachability? (We're > > interested in making things "just work right" on all kinds of > > platforms.) > > > After reading the article in The Register[1] I'd be pleased to toss a > +1 your way, yes. > > [1] http://www.theregister.co.uk/2005/08/16/solaris_x86_not_too_shabby/ Thanks--I'll find out the next steps from Jim G. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris Tech Lead
Thanks to all for the warm welcome. I'm still getting caught up on the complete contents of the program's "to do" list, but am always ready to hear about blocking issues, be they to do with released source, site and tools infrastructure, new systems ideas, or even random speculation. Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No kernel source updates?
* Felix Schulte <[EMAIL PROTECTED]> [2005-08-24 13:14]:
> Today we had a slightly bad discussion on irc.freenode.de about
> OpenSolaris being a marketing move and no real project (main argument:
> no source updates since 14-Jun-2005) and the guy ("jinderhawk")
> prepares a story on slashdot based on that discussion... any comments?
The current source on the Sun Download Center is dated 18 August; this
corresponds to Build 20, I believe. There was an earlier release on
20 July, still available at genunix.org.
See http://www.opensolaris.org/os/downloads for links to the various
sites for download.
- Stephen
* Steve Lau blogged about the most recent drop:
http://whacked.net/2005/08/18/releasing-nevada-build-20/
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED] http://blogs.sun.com/sch/
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No kernel source updates?
* Felix Schulte <[EMAIL PROTECTED]> [2005-08-24 13:30]: > On 8/24/05, Patrick Mauritz <[EMAIL PROTECTED]> wrote: > > On Wed, 2005-08-24 at 22:14, Felix Schulte wrote: > > > any comments? > > see http://www.openbios.org/~oxygene/opensolaris.txt.bz2 > > Is there no Bonsai/CVSblame for the source tree at opensolaris.org? > > >for what > > changed in the various source drops (06-12, 07-01, 07-20, 08-18) > > These are code drops but contain zero content information *why* things > were changed (3rd claim from IRC: Sun provides no changelog and > per-issue source diff, making the project useless for non-sun > contributors). The claim is currently accurate. Publishing change histories in some form or other is planned but not present in the current drops or the source browser. That said, we have taken and are taking patches from community members, so perhaps "making the project useless" is too strong a phrase here. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] priorities for additional Solaris consolidations
* Darren J Moffat <[EMAIL PROTECTED]> [2005-09-07 10:27]: > On Wed, 2005-09-07 at 01:51, Karyn Ritter wrote: > > Consolidation Priority > > -- > > Sun Java System Application ServerLOW > > Isn't this already open source and under the CDDL license ? > > https://glassfish.dev.java.net/ > > Glassfish is to Sun Java System Application Server PE[1] what > OpenSolaris is to Solaris. > > > [1] PE = Platform Edition, this is the edition included in Solaris > and bundled with developer tools like NetBeans. There is also > Enterprise Edition which is available only as part of the Sun Java > Enterprise System and is not free or open source. The priorities are with respect to opensolaris work: because of GlassFish, the need for opening the source associated with the version shipped in Solaris is deemed to be small. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] priorities for additional Solaris consolidations
* John Plocher <[EMAIL PROTECTED]> [2005-09-07 10:49]: > Karyn Ritter wrote: > >I've pulled together my preliminary thoughts on the relative priorities Karyn's complete sentence was precise: > I've pulled together my preliminary thoughts on the relative > priorities of open sourcing the other Solaris consolidations, and > would like you all to comment on the list and priorities below. > From my perspective, the priorities are > > HIGH: All the things needed to make OpenSolaris > a bootable, installable and updatable distro. Support of community members pursuing this goal is in fact reflected in the priorities in the original list. The notion of a reference distribution is a governance issue. > HIGH: Teamware AS-IS and SCCS, followed by some SCM decision. Beyond SCCS, no SCM functionality is shipped in Solaris currently by any consolidation. DevPro is a high priority consolidation as a result of its containing libm, SCCS, and other components believed to be of interest. The general SCM issues are separate from helping consolidations understand the level of interest the community might have in their source. > Once this state has been reached, the rest of the > consolidations can be ranked by simple desire; without > this stuff, the other consolidations are not very useful. I disagree with this on a number of levels but, most of all, I disagree with the implied serialization. > >OS/Networking HIGH > Isn't this already *done*? There are still components being examined, as well as a influx of new projects. > >Administrative Tools LOW > >DEVPROHIGH > >Documentation: Open Source Solaris Man Pages HIGH > >Install: Packaging Tools HIGH > >Networking > How is this different from what is already there? This refers to the various SPARC platform network drivers not in ON. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Program technical status and directions, 9 September 2005
call out that we have added additional sponsors for ON and that John Beck has been working to close some gaps in sponsor technical coverage, so that code fixes submitted during this interim phase don't get chilled waiting for a sponsor. Feedback welcome. I'll read it all, but I can't promise replies to all. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ - End forwarded message - -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: SCM (was "http://cvs.opensolaris.org update")
* Glynn Foster <[EMAIL PROTECTED]> [2005-10-05 15:55]: > Hey, > > On Wed, 2005-10-05 at 13:30 -0700, Mike Kupfer wrote: > > There are two phases for the SCM work. (Or at least that's how I'm > > thinking about it for this discussion.) The first is to provide a > > centralized SCM, which will at least get us off the tarballs. That's > > what we plan to use Subversion for. > > > > The second phase is distributed SCM. > > > > Are you asking about discussion of the centralized SCM, the distributed > > SCM, or both? > > Mostly both, although as I understood Subversion was a contender for > both - without really having done my homework to see if that was > actually the case. I guess there's a 2 step migration of ON being > planned - first to a centralized repository, and then adding the > distributed element after that? Subversion isn't a distributed SCM, so it's not a contender for that portion. (The simplest way to identify a distributed SCM is that one repository can pull from or push to any other as a natural operation.) The intent is to offer one-way, read-only repository access for ON and other TeamWare consolidations via a limited bridge to Subversion. This is an interim solution for the consolidations interested in continuing to use a distributed SCM: ON will move directly to a distributed SCM solution (which could be an improved version of TeamWare) once identified. I owe the alias the draft requirements for the distributed SCM, but have a few other documents to finish first. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: SCM (was "http://cvs.opensolaris.org update")
* Glynn Foster <[EMAIL PROTECTED]> [2005-10-05 16:19]:
> Hey,
>
> On Wed, 2005-10-05 at 16:04 -0700, Mike Kupfer wrote:
> > >>>>> "Glynn" == Glynn Foster <[EMAIL PROTECTED]> writes:
> >
> > Glynn> I guess there's a 2 step migration of ON being planned - first to
> > Glynn> a centralized repository, and then adding the distributed element
> > Glynn> after that?
> >
> > No, just one migration. The plan is for ON to provide a one-way gateway
> > to a read-only Subversion repository.
>
> So, that sounds like it's only a half step towards moving to Subversion
> full time - but you comment is a little sparse on details so I could
> have completely misunderstood what you were suggesting.
>
> Does anyone have a good technical writeup of what is being planned -
> mostly because other consolidations are likely to be effected as well,
> and it would be good to have some heads up so we can work on a good
> migration story.
The previous summary* I thought precise, but I suppose that's suspect:
2. Source code management, first phase.
The Code Manager ("TeamWare") distributed source code manager
(SCM) has been in use at Sun for over twelve years; its
predecessors were also distributed SCM solutions. It is
difficult to envision how we might move the current practices of
the consolidations using TeamWare to an SCM that doesn't match up
well with the features and extensions that have been in use for
so long. However, TeamWare itself has deficits when we consider
its use on the open Internet (and even within Sun's wide area
network).
In order to make progress, and in order to support new and
current projects and consolidations that are not tied to
TeamWare, I believe that we must offer a centralized SCM facility
while the current set of open source distributed SCM solutions
are evaluated against criteria based on TeamWare's use within Sun
and on suitability for use on an Internet-hosted site. Luckily,
recent developments in the SCM space suggest that one or more
SCMs may meet many of these criteria already. A draft set of
criteria will be published shortly, after which candidate SCMs
will be evaluated against them.
The proposed centralized SCM solution is Subversion, based on
features, ease of integration, and community vigor. Information
on Subversion may be found at
http://subversion.tigris.org/
Tools to make the source drops of TeamWare-based consolidations
available via a read-only repository will also be
found/refined/developed. We will publish a representation of ON
via a read-only repository during this phase.
That is, if a consolidation wants centralized SCM access, then it will
be able to use Subversion, once the site support has been implemented.
If a consolidation wants distributed SCM, then it has to wait for an
evaluation phase to complete, and then for the implementation of site
support. Thus, migration issues can only be currently engaged with by
consolidations that believe the centralized facility is sufficient for
their needs.
Basic project hosting will be implemented first.
- Stephen
* http://www.opensolaris.org/jive/thread.jspa?threadID=2174
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED] http://blogs.sun.com/sch/
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] docs on SMF
* mnikhil m <[EMAIL PROTECTED]> [2005-10-06 12:00]: > I am thinking of writing some custon smfs ..in this regard, can someone > please point me to quick and relevant SMF tutorials on open solaris.. See the links off http://opensolaris.org/os/community/smf/ - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New Community Request
* Tim McMurphy <[EMAIL PROTECTED]> [2005-10-07 14:40]: > I would like to start a community group with the focus of running > other operating systems inside a zone. This would look at optimizing > opensource software like bochs and/or qemu for the OpenSolaris > project. > > This is different from the Xen project in that we would use Solaris as > the hypervisor with its rich set of resource control and then emulate > x86 systems inside a zone. > > So far as a proof of concept I have run FreeDOS inside a zone on a > Sparc system using bochs. It was very slow. Evaluating what > optimizations can done and running it on Solaris x86 is my next > planned step. > > While this approach will be slower than Xen it is still interesting to > look into. That and processors are not going to get any slower. At > some point even emulating an entire x86 system in software will become > realistic. Neat. Would you be interested in a Virtualization community, with your kind of work, Zones, Xen, and some other projects all discussing common issues? - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] ZFS forum yet?
* Rich Teer <[EMAIL PROTECTED]> [2005-11-01 19:18]: > On Tue, 1 Nov 2005, Richard L. Hamilton wrote: > > >Rumor is the developers got somewhere with ZFS integration, and at least > >Solaris Express may > >see ZFS soon; presumably OpenSolaris some time thereafter? So maybe a > >forum specifically > > If anything, OpenSOlaris will see ZFS before Solaris Express. > But a ZFS community wouldn't be a bad idea. I think the wheels > are in motion to "make it so". Dan Price proposed it last week: http://www.opensolaris.org/jive/thread.jspa?threadID=2636&tstart=15 At the end of that thread and based on the conversation to that point, Derek Cicero said he would create it. The next steps, as with all new communities, are for the initial community leads to get some minimal content up and activate the community. (Since the ZFS team is recovering from potentially months of sleep deprivation, I predict these steps might not take place for a week or so.) As Rich also notes, ZFS will show up here (and in the special-for-OpenSolaris Community Express edition) before anywhere else. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Storage drivers availability
* Cyril Plisko <[EMAIL PROTECTED]> [2005-11-02 06:42]: > Hi, > > http://opensolaris.org/os/about/roadmap/ suggests that Sun storage > drivers would be released in October. Which at this stage would require > a time machine to achieve since we are in November already. > Are there any updates to the release schedule ? We'll try to keep the roadmap up to date, but if you want regular status, monitor [EMAIL PROTECTED]'s where consolidations discuss and report on getting opened. For instance, in Linda's notes from the 10/24 meeting, I see: Aaron Dailey (Network Storage): === * A couple people still need to sign off on due diligence. * Sent out an announcement for building a storage community. * Targeting end of this week for release. No feedback from Winnie & Marilyn. * Will check on whether categories have been added to bugs.sun.com. (So I guess Aaron's stuck in the time machine's booth.) Linda's complete 10/24 notes are available at http://www.opensolaris.org/jive/thread.jspa?threadID=3069&tstart=0 for those interested. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Opensolaris vs Solaris
* Marcel Luternauer <[EMAIL PROTECTED]> [2005-11-02 13:02]: > I am confused by reading: > http://opensolaris.org/os/community/onnv/os_dev_process/#goals > > [b]Quality > OpenSolaris should have the same criteria for quality, security, etc. as > Solaris.[/b] > > This sounds like Opensolaris and Solaris are two branches of > development. I this the case? I thought that Opensolaris and Solaris > are containing the same sourcecode. Marcel, Thanks: we'll get this clarified for the next revision, which I believe the development process team will be releasing for comments in the coming week. (It may already have been fixed... yep, appears so.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] community proposal: Linux Immigrants
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2005-11-03 08:46]: > > >On Wed, 2 Nov 2005, Adam Leventhal wrote: > > > >> There seems to be at least a loose concensus that this would be a useful > >> community. Any +1 votes from the CAB? > > > >+1 > > +1 Absolutely agree. > > I think we should also be open for those in exile such as South > Koreans who may seen be exiled from Windows :-) Now that the community creation process has been satisfied, we'll get this community established. Based on my reading of the thread, this is the "immigrants" community. Or is it "linux-immigrants" still? Adam? - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] community proposal: Linux Immigrants
* Adam Leventhal <[EMAIL PROTECTED]> [2005-11-03 09:36]: > On Thu, Nov 03, 2005 at 09:06:34AM -0800, Stephen Hahn wrote: > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2005-11-03 08:46]: > > > > > > >On Wed, 2 Nov 2005, Adam Leventhal wrote: > > > > > > > >> There seems to be at least a loose concensus that this would be a > > > >> useful > > > >> community. Any +1 votes from the CAB? > > > > > > > >+1 > > > > > > +1 Absolutely agree. > > > > > > I think we should also be open for those in exile such as South > > > Koreans who may seen be exiled from Windows :-) > > > > Now that the community creation process has been satisfied, we'll get > > this community established. Based on my reading of the thread, this > > is the "immigrants" community. Or is it "linux-immigrants" still? > > I'd like this to be linux-immigrants with the understanding that > freebsd-immigrants and others might not be far behind and that they may some > day all fall under the umbrella of a larger immigrant community. But, > as Patrick Finch suggested, starting with the more specific version might > be the best way to grow interest in the linux-immigrant community and > later in other immigrant communities. Okay. Derek and I will spend a few minutes thinking about how we might deal with a futura umbrella immigrants community but, and anticipating Adam's investment of energy, we'll get linux-immigrants set up. Let's make sure the immigration team stays in touch with the user groups community and the folks on opensolaris-help. Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] We need a binary license for pkg* immediately
* Dennis Clarke <[EMAIL PROTECTED]> [2005-11-07 09:38]: > On 11/7/05, Joerg Schilling <[EMAIL PROTECTED]> wrote: > > the Subject says it all! :-) > > > > It would be very helpful if there was at least a binary redistribution > > license available for the PKG tools. This does not help the PPC porting > > project, but it allows to use Blastwave packages with SchilliX > > Even more important, it allows for packages that are built within the > framework of the SVR4 spec to be made portable to other distros. > While the ISO/IEC 9945-2003 spec provides for a package standard as > does the POSIX ( see the Open Group also ) we need an actual > implementation that is functional. > > The pkgadd/pkgtrans/pkgrm tools ( et al ) provide this within Solaris > for years and years and people expect them. They also trust them. I will check on our status; I know that we have been through the source files, and closing in on how to get the package tools published (i.e. in one delivery or two, with binaries first). - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Program technical status, 7 November
It's been two months since my initial status message, which is probably a bit too long. Most of the efforts I mentioned in that update have made progress, so it's worth mentioning their current status: 1. Elementary project hosting support. The web site development for simple project hosting is underway. At present, those enhancements are expected for delivery sometime in December. (You may have noticed that a number of issues with the site were recently fixed.) In parallel, we are attempting to eliminate some of the manual steps in community and project creation. 2. Source code management (SCM), first phase. The first phase of source code management involves adding Subversion hosting for individual projects and for the ON consolidation to publish ongoing changes in a read-only Subversion repository. Prototyping for the former has begun, but is dependent on the elementary project hosting work. For ON, Stephen Lau has been experimenting with publishing a "squelched" SCCS history; you can see the result of Chandan integrating this work in the latest release of the source browser. For instance, here's a file with some recent revisions and also the squelched history: http://cvs.opensolaris.org/source/history/on/usr/src/cmd/svc/configd/configd.h This work, along with some SCCS and TeamWare insights gleaned by Alan Burlison, is expected to be the basis of any SCM migration we pursue, as well as for the short term read-only Subversion publication. 3. Partitioned ON source tree. The partitioned ON source tree is undergoing internal code review--internal only due to the encumbered code involved. Mike Kupfer gave much more detail in a recent blog entry http://blogs.sun.com/roller/page/kupfer?entry=on_the_road_to_nightly As noted in my previous update, a partitioned tree means that projects can issue public source drops of their development code, and get proper community development going. 4. ON GCC readiness. Bug fixes that eliminate GCC warnings have continued to integrate into the Nevada gate. As a result, we're now able to finish drafting a cleanliness policy for integrations and making the tools changes to support them. This policy will be discussed in the Tools community, once the draft is complete. Because we've been making progress on those initial items, new aspects of the program will receive more attention. The two new areas of focus are discussed below. 5. Governance development. The development of the governance for the OpenSolaris community is being led by the CAB. One effort in support of that has been creating a document articulating the engineering values that go into OpenSolaris software, as well as a process that contributors can follow that results in the production of such software. The most recent draft of the development process is available as HTML http://www.opensolaris.org/os/community/onnv/os_dev_process/ or as PDF http://www.opensolaris.org/os/community/onnv/os_dev_process/d-devproc-alpha.pdf If you're subscribed to cab-discuss, you know that drafts of the charter, which transfers responsibilities for OpenSolaris to the community from Sun, are being vigorously discussed in that forum. We're attempting to keep the various stakeholders engaged so that the charter document can be completed and ratified promptly. 6. SCM, second phase. The evaluation of a distributed SCM solution will be pursued directly now. I'll be issuing draft requirements and an initial candidate list very shortly; this discussion will take place in the Tools community, although I'll send a notice to opensolaris-discuss. In terms of source releases, I thought I should also mention that libm, the C math library, was released in binary form in the past month. Cleaning up the source code for release is in progress. And, as I mentioned in another thread, team members have reviewed the packaging tools source and are working out whether a two step release is needed there as well. The Java Desktop System consolidation successfully published their code last week; other consolidations are getting close to releasing their trees as well. As always, please share your concerns; I am happy to receive them privately or on the list. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: New Community Request
* Matthew Simmons <[EMAIL PROTECTED]> [2005-11-08 09:15]: > I don't see the problem with using the code name for a project as the > community name, knowing that later on you may need to rename the > community when marketing invents a new name for it. Try as we might, > we're never going to guess that name in advance. The infrastructure team is extremely uninterested in supporting project or community renames after they go live. As as additional comment, "marketing names" are associated with distributions and not the source tree shared across the community. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: New Community Request
* Matthew Simmons <[EMAIL PROTECTED]> [2005-11-08 09:53]: > >>>>> "SH" == Stephen Hahn <[EMAIL PROTECTED]> writes: > > SH> As as additional comment, "marketing names" are associated with > SH> distributions and not the source tree shared across the community. > > So are we going to maintain a separate mapping somewhere so that users coming > to the OpenSolaris pages from a Solaris-based existence know how to find the > communities that correspond to the Solaris features they've come to know and > love? There are a couple of communities that might choose to do that on opensolaris.org; with respect to Sun, sun.com is the appropriate place to connect named technologies to the communities/projects from which they originate. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is opensolaris express completely opensource?
* Darren J Moffat <[EMAIL PROTECTED]> [2005-11-11 02:24]: > Once the gate split putback happens (I just finished my codereview > of it yesterday) we can then go and rip out all of the EXPORT/CRYPT > stuff that is in the usr/src (ie the OpenSolaris) part. Its actually > quite a big job with very little payoff for but it does need to get > done. Let us say that the immediate payoff seems disproportionate to the amount of work invested. However, since it means that internal work that has been chafing--hi, Tim; hi, Nils--to get out into the community can do so with little effort, the medium term payoff is substantial. (Plus, since there will be a stigma associated with each /closed integration, the long term potential benefit is very great.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Redistributable pkg/make/sccs binaries
I thought I should note that the packaging tools and also make(1S) and sccs(1) have been released as redistributable binaries: http://opensolaris.org/os/community/tools/pkgtools/ http://opensolaris.org/os/community/tools/devpro/ Discussion of specific issues will be in [EMAIL PROTECTED] Thanks to the individuals and teams involved; we are of course still working to a source release of these components. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] coding style
* Paul Durrant <[EMAIL PROTECTED]> [2005-11-23 09:51]: > Apologies if this has been asked before... > > Is the Sun coding style doc. available to the opensolaris community? > Given that, I presume, code taken from contributors from outside Sun > still has to pass the standard ON cstyle/hdrchk stuff it would be > useful to have the doc. as a reference. It is http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms.pdf (It's linked to from the Nevada community page, which is what the unbelievably big Developer's Reference currently calls home.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Draft SCM requirements published
These two threads on [EMAIL PROTECTED] are the locations of the requirements http://www.opensolaris.org/jive/thread.jspa?threadID=3982&tstart=0 and the initial list of candidates http://www.opensolaris.org/jive/thread.jspa?threadID=3991&tstart=0 Have a look; join tools-discuss (or use the forums); send your feedback. (And, if you've built GHC for Solaris x86, please let me know.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: New Community Request
* Nils Nieuwejaar <[EMAIL PROTECTED]> [2005-11-20 08:11]: > > It appears that BrandX as a name is not going to fly as somebody already > > has that name trademarked. We have an alternative name in mind, and > > I'm told the lawyers are doing their lawyerly stuff with it now. > > We have gotten all the sign-offs we need to go with the new name: BrandZ. > This is shorthand for Branded Zones so, in addition to not being > lawsuit-bait, it actually means a little more than the original name. If > this name is acceptable to everybody, then hopefully we'll be able to get > the community up and running in short order. In the interest of wrapping this up, and in attempt to follow http://www.opensolaris.org/jive/message.jspa?messageID=7336#7336 (being unable to find the message it cites, although I recall it...) I want to get: - at least one CAB member to issue a +1, - a verification that the proposed community's leads and the Zones community leads were not able to share the Zones community with the union of those sets of leads, and - that investigation of an umbrella Virtualization community is not being pursued in the near term. As a side note, we'll have Projects hosting support in a few weeks or less, so technical efforts that want to start smaller can do so without seeking wider approval. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: New Community Request
* Nils Nieuwejaar <[EMAIL PROTECTED]> [2005-12-05 12:00]: > > - a verification that the proposed community's leads and the Zones > > community leads were not able to share the Zones community with the > > union of those sets of leads, and > > While it would be possible for BrandZ and Zones to share a single community, > the amount of overlap would likely be fairly small. Most people who are > interested in zones will have little interest in BrandZ, and vice versa. I > talked > about this offline with Dan, who originally proposed the joint community, and > he > is OK with the current proposal to split the two. > > > - that investigation of an umbrella Virtualization community is not > > being pursued in the near term. > > It is not. If opensolaris.org introduces a notion of meta-communities or > community clusters in the future, we will revisit this idea. Thanks Al and Nils. Now that some consensus has been reached, the BrandZ community will be created. Community leads can make the decision to make the community visible when their content is ready. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Please update 4113420 (request for ksh93 integration)
* Felix Schulte <[EMAIL PROTECTED]> [2006-01-09 15:39]: > On 1/9/06, James Carlson <[EMAIL PROTECTED]> wrote: > > But someone needs to do the work of figuring out what that breakage > > is, whom it would affect, how, and documenting all of that as a > > proposed project. > > James... several YEARS ago someone from our university > ([EMAIL PROTECTED]) already created a quite > painless ksh88-to-ksh93 migration plan (including a detailed list of > issues which need to be solved) for Solaris and send the proposal to > Sun, however Sun did not had any interest in such a work. Much has changed between then and now; maybe sending that document to this alias might have more effect (since the question about kinds of impact has been posed and the document may answer it fully) than the previous submission? - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] CIFS group creation request.
* Darren J Moffat <[EMAIL PROTECTED]> [2006-01-12 03:35]: > On Thu, 2006-01-12 at 10:22, Alan DuBoff wrote: > > On Wednesday 11 January 2006 09:58 am, Mark Sweeney wrote: > I see communities as being the long term high level thing and projects > being the shorter term or smaller scope things. > > I don't really care either way but it does beg why we have both projects > and communities. Communities are the social groups representing areas of interest within the entirety of the OpenSolaris space, and will have some kind of representation in the governance process (or they do in the current draft). As a result, the preliminary process for creating community requires a reasonable amount of consensus, including a CAB endorsement. Projects are collaborative efforts that produce objects (code changes, specific documents, graphics, etc.). Projects will have code repositories, committers, etc.; communities won't. The process for requesting a project requires only two community members to agree. (The infrastructure requirements of the two groupings overlap, but having only one type of grouping leads to a very complex "leader" console that looked forbodingly difficult to implement well and to document completely.) I think your duration point will be accurate in general. - Stephen ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] CIFS group creation request.
Speaking in the most bureaucratic manner I can muster, you need to decide whether your efforts require a project or a community. If your intent is to produce code or a structured best practice document or some other form of collaboratively authored product, then I recommend that you request a CIFS project, in which case you need to send mail to this alias like that of the network-sip project http://www.opensolaris.org/jive/thread.jspa?threadID=4968&tstart=0 and find a seconder. If you believe that many CIFS projects might spawn from a long and wide-ranging discussion, and that such a discussion should be distinct from those of the SVM, UFS, and ZFS communities, then you need to articulate by email to this alias how a CIFS community is needed, meaningful, and separate, similar to the recent Appliances community proposal http://www.opensolaris.org/jive/thread.jspa?threadID=4945&tstart=0 (which, I note, mentions a zfs-Samba combination in the thread) and then either consensus, including CAB assent, or criticism will emerge. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal: OpenSolaris Articles Project
I've seen a couple of points following the "Articles" project proposal that appear to require clarification. 1. The Articles project proposal is proposing a project, not a community, and therefore follows the project proposal process. This process means that the proposal must be seconded to be approved. According to the forum listing, at least the first three replies expressed support for the Articles project. 2. The Articles project has no preexisting relationship with any community. The relationship between this project and any existing (or future) community is yet to be negotiated. If the project never becomes meaningful to users directly, or through a community, that's okay. (Conversely, it is fine for a would-be project proposer to negotiate community endorsements in advance; it is not, however, necessary.) 3. BigAdmin is a web property owned by Sun Microsystems. Its aims are not necessarily those of any project or community associated with OpenSolaris. I wouldn't use its existence--or any Sun program's--as a reason not to start an OpenSolaris project, as Sun probably has a program for everything... If you believe the current project proposal process is insufficiently heavyweight or lacks controlling input from potentially related communities, please comment to that effect on [EMAIL PROTECTED] - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community Forum Proposal: Packaging, Patching, and Distribution Mgmt
* Dave Miner <[EMAIL PROTECTED]> [2006-02-01 13:15]: > I imagine it's implicit in my being listed as a community lead ;-), but > I do give this a +1. > > Just to elaborate a little on the proposal, this community would be the > home for the SVR4 packaging tools code when it's released in the near > future, as well as other packaging and installation projects. Is this then the "packaging and installation" community? (The currently proposed name is pretty specific...) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal: ksh93 integration project
* Roland Mainz <[EMAIL PROTECTED]> [2006-02-07 17:30]: > - enhancement of Solaris tools to use libshell instead of homegrown > commandline parsers (like mdb, zfs, xauth etc.) > - replacement of duplicate ksh versions in various Sun products with > libshell.so (which is ksh93 as a shared library), including dbx and > dtksh These two points are "explore enhancement" and "explore replacement", I think. For instance, mdb has terminal handling (so that its kmdb variant can have civilized input as well) and is constrained to have a language syntax that is an extension of adb(1)'s, as an example of where integrating libshell is potentially of limited benefit. I also wonder if you should propose a modern-cmds project (since folks have complained about other specific "old versions") with ksh being the first topic. - Stephen ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Proposal: ksh93 integration project
* Roland Mainz <[EMAIL PROTECTED]> [2006-02-08 12:41]: > Stephen Hahn wrote: > > I also wonder if you should propose a modern-cmds project (since folks > > have complained about other specific "old versions") with ksh being > > the first topic. > > Uhm... in theory such a project would be nice but first I'd like to > focus on ksh93 - which is already a quite large beast to handle > (assuming libshell, libc, profile shells, bugfixing and some sort of > backwards-compatibility+migration tools should be handeled, too.). > There will likely some affects on the normal commands (for example to > sync /usr/bin/sleep to work like the ksh93 buildin version (e.g. > allowing fractions of a second instead of just accepting plain integers > (example: % /usr/bin/sleep 0.5 # should wait exactly a half second))) - > but for enhanching the commands in /usr/bin/ it may be nice to have a > seperate project which also syncs the changes/updates to the commands > with the people who are doing the Unix*-standards (e.g. Unix98, Unix2003 > etc.). I accept your precise scope for the ksh93 project. I'll defer to Keith to second. Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] genunix wiki online
* Calum Benson <[EMAIL PROTECTED]> [2006-02-13 04:26]: > > On 12 Feb 2006, at 05:20, Glynn Foster wrote: > > >Hey, > > > >On Fri, 2006-02-10 at 16:35 -0600, Al Hopper wrote: > >>Thanks to the hard work of our own Ben Rockwood, the wiki for > >>OpenSolaris > >>related activity is available at: www.genunix.org/wiki/ > >> > >>One of the items slated for "development" on the wiki is the > >>OpenSolaris > >>Governance document now known as the OpenSolaris Constitution. > >>Leading > >>this effort will be the CAB/OGB along with our special appointees: > >>Ben > >>Rockwood and Keith Wesolowski. > > > >Coolness, thanks to those who set it up - now can we redirect > >something > >like http://wiki.opensolaris.org to the genunix site for ease of use? > > +1... and is there any chance it can be configured to use our > existing OpenSolaris logins, rather than having to create /yet/ > another *&^$&^%^£ account? Personally, I have to say I'd have > preferred to see it hosted directly on opensolaris.org, so we didn't > have to do extra work for this sort of integration, but too late now > I guess. > > (And unfortunately it uses a different wiki syntax to most of the > wikis we use inside Sun, so it possibly wasn't the best choice for > helping us to transition as much stuff as we can from there into the > open :/ Possibly addressable with a bit of careful sedding, though...) Some comments: 1. The primary present goals of the infrastructure team are to build support for repository hosting and for voting/balloting for the eventual OGB elections. Our resources are very much finite, so this constrait means that some of the "might be nice to have" items are not being pursued. 2. It is our intent to make the user account database available for login purposes on other sites. We've looked at some of the identity web services, as well as a potential LDAP deployment, but we're not going to investigate further until a number of other items are complete. Integration of any particular package with the site should not be assumed trivial. 3. Project teams have the ability to post content today. The repository hosting work will make automated postings (or mass transfers) easier. (But I am not claiming wiki equivalence-- merely that the site will be "good enough" for many purposes.) 4. Any wiki content on opensolaris.org would be covered by the site's Terms of Use. I am uncertain that all the participants in the current wikis would agree to contributions under such terms. Being the system pointed to by a CNAME record from opensolaris.org is more of a grey area, I suppose. That said, if you have a link for the "Community Links" page, please submit it to [EMAIL PROTECTED] Since there was no wiki section on that page, I've added the genunix and wikicities wikis in a new subsection of the Communities and Sites section. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: CDE Vs JDS
* Joerg Schilling <[EMAIL PROTECTED]> [2006-02-14 08:55]: > Alan Coopersmith <[EMAIL PROTECTED]> wrote: > > > Qt licensing was part of it, avoiding the nightmare of C++ binary > > incompatibility between compilers (or even between different g++ versions) > > was another. The official FAQ answer is at: > > > > http://www.sun.com/software/star/gnome/faq/generalfaq.xml#q23 > > Mmm, how is this related to star? I believe it's reflecting the organizational genealogy, as GNOME's first home was alongside the then-newly-acquired StarDivision. (Sun historians should feel free to correct me.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community/Project Update: 2/13/06
* Anup Sekhar <[EMAIL PROTECTED]> [2006-02-14 08:21]: > Jim Grisanzio wrote on 02/13/06 17:39: > >Here's an update on community and project proposals. > . . . > > >Name Services Community > >* Proposed 1/20/06 by Anup Sekhar > >* Community consensus: yes > >* CAB vote: no ± vote yet > >* Opening date: currently not scheduled > > Is is possible to get closure on whether or not the CAB approves > this community? I am not sure if there is a timer that the > CAB has set for new community proposals. If not, that would > be a suggestion so that people are not left hanging. If we can't > get a community, we will likely go with a project proposal but > don't want to move forward on that until this is finalized. 30 days is what we're using. That leaves about a week to elicit/solicit a CAB sponsor--perhaps you have additional details about why this community is distinct from, say, the networking or sysadmin communities that might help a CAB sponsor see the contribution the proposed community's discussion would make. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New Community Proposal: Solaris on zSeries Mainframe Server
* Jeff Andre <[EMAIL PROTECTED]> [2006-02-14 05:34]: > A number of engineers on the Data Management Group are working on a > port of Solaris to the zSeries mainframe servers and we'd like to > establish a community supporting and promoting a port. The initial > efforts of this port would allow the Solaris operating system to > execute as a guest on a zSeries Virtual Machine facility and the > Hercules mainframe emulator, http://www.conmicro.cx/hercules/. If > there was sufficient justification for the effort the port would then > address running Solaris in a native partition. > > Through this community we'd build a network of developers focused on > effecting this port. > > We see this port as an opportunity to make Solaris the Internet > interface to the large stores of mainframe centric data frequently > being accessed by Linux today. We feel that Solaris has a number of > attributes that will provide significant benefits over the Linux > mainframe implementation. > > >From prior posts on the general discussion list there is an interest > >within the community for porting Solaris to the mainframe. It is > >expected that the level of participation will be somewhat focused to > >as limited group of developers due to lack of publicly available > >facilities on which to develop the port. However, the Hercules > >emulator will allow anyone with an interest to participate. > > Thoughts, suggestions, and questions are welcome. This proposal should almost certainly be a project, and not a community. (Many of the current communities are grandfathered from the pilot program, and should not be used as models for subsequent proposals.) If you wish to have a project, just say so, and have someone (from the team) second the proposal. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: New Community Proposal: Solaris on zSeries Mainframe Server
* Jeff Andre <[EMAIL PROTECTED]> [2006-02-14 11:57]: > I'm not sure I understand the significance of a community versus a project. > > Who needs to second the proposal, someone else working on it here or > within the OpenSolaris community? See the leading paragraphs of http://opensolaris.org/os/projects/ http://opensolaris.org/os/communities/ for brief discussions of each. The technical difference is that communities have some planned participation in overall governance (while projects do not) and projects will have source repositories (while communities will not). - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: New Community Proposal: Solaris on zSeries Mainframe Server
* Jeff Andre <[EMAIL PROTECTED]> [2006-02-14 14:34]: > OK, I see the difference; it doesn't seem quite right that you can > have a project without it being part of a community. It allows people to start working on a specific item--and have supporting infrastructure--before any community is convinced that the project is "worthwhile" in their judgment. > So, we want to change this proposal from a community to a project. Second? (Pat is fine.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: CDE Vs JDS
* UNIX admin <[EMAIL PROTECTED]> [2006-02-15 03:50]: > > If expanding adoption of Solaris as a better > > alternative is a community > > goal, then addressing the lack of GUI admin tools > > might help accomplish > > that goal. Check out the Visual Panels project if > > you haven't already, > > some good ideas there: > > > > http://www.opensolaris.org/os/project/vpanels/ > > That says a whole lot without actually saying anything. If only there were > one single screenshot of the thing, it would most likely be sufficient to > replace the tons of text on that page. > > As it stands right now, it's all completely abstract. They have screenshots http://www.opensolaris.org/os/project/vpanels/screenshots/ and code http://www.opensolaris.org/os/project/vpanels/install/ (The left hand nav bar has links to the various pages that each project or community provides.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What is the relationship between OpenSolaris and SolarisExpress/community?
* Alan DuBoff <[EMAIL PROTECTED]> [2006-02-17 15:37]: > On Friday 17 February 2006 01:19 pm, Keith M Wesolowski wrote: > > On Fri, Feb 17, 2006 at 01:05:05PM -0800, Robert wrote: > > > Now when Solaris Express/Community puts out new builds (and so does > > > OpenSolaris :-) ) all the time; What is the relationship between > > > theese when it comes to updates? > > > > Solaris 10 Updates may contain code originally introduced in > > OpenSolaris but there are no Updates made for either Solaris Express > > or OpenSolaris (OpenSolaris isn't a product, so there's nothing to > > update - the code is continually changing as active development > > proceeds). > > Let's ask the question this way. > > Is there any possibility that we'll be seeing source control on opensolaris, > so that it would be possible to putback to the opensolaris gate, rather than > go through Solaris? > > This is something I want to see, so could be considered on my agenda, but > without source control it seems everyone has their hands tied. > > Not pointing this question directly at you Keith, I know there are many > things > that could need to happen that would allow this scenario to happen, and that > need to. Just posing this question because we seem to be hinged on source > control to really be able to manage the source in the opensolaris community. Numerous threads in tools-discuss deal with the selection and deployment of SCM solutions for opensolaris.org. I am unsure how Robert's question relates to yours; the answer I might have given would be "Express is Sun's unsupported distribution of OpenSolaris plus other pieces; Updates are patches to the previously shipped supported distribution." In terms of source, that means an integration into OpenSolaris may also be backported by Sun to its patch repositories for its prior releases, although the effort associated with and the contents of that backport may not be identical to that expended or committed to the development repository. At present, I do not believe the other distributions are maintaining patch repositories against their previous releases, so this notion of backports is specific to Solaris. It is very possible that those distribution teams might choose to do so, as they acquire larger user bases. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: "Resource Management"
* stephen lawrence <[EMAIL PROTECTED]> [2006-02-24 15:31]: > I'd like to add a project for exploring and discussing matters related > to resource management. This project should be of particular interest > to the Zones community in terms of making each zone's resource > isolation stronger and its configuration simpler; other communities > may wish to endorse this project as well, such as the SMF, System > Administrators, and Approachability communities. > > Initial Project goals: > > - Gather requirements and design enhancements to extended accounting > and system monitoring subsystems. > - Design and implement solutions for usability issues within the pools > administrative interfaces. > - Explore and discuss new resource controls. > - Explore and discuss resource allocation and/or scheduling options. > - Explore and discuss interfaces for resource management > administration > on zones. > - Address existing and new bugs and RFEs within solaris resource > controls, resource pools, projects, tasks, and extended accounting. > > This is intended as an umbrella project under which to explore, discuss, > design, and implement resource management related features. Large > technical efforts might generate separate projects. I'll second this proposal: I like resource management (and you should, too?). - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] BeleniX 0.4 Released
* Moinak Ghosh <[EMAIL PROTECTED]> [2006-02-24 10:02]:
> * The most significant is the addition of on-the-fly decompression support
> to the lofi kernel module using zlib and very little kernel memory
> requirement.
> This allows packing in 1.5 GB of opensource software under /usr with
> space
> for more.
>
> CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/belenix
> export CVSROOT
>
> cvs -z3 co livecdtools
I'm curious about the implementation of the compression handling in
lofi/lofiadm, so I suspect others might be as well; can you give the
CVS paths to that portion, or will we see this feature proposed on
opensolaris-{code,rfe} soon?
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED] http://blogs.sun.com/sch/
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXCR/onnv status
In the disks are free vein, how hard would it be to also release the respun ON build sources? Or at least to mark the weekly release that turned out to be the same as its build? (Steve's and/or the gatekeepers' time is not free, so a menagerie of releases isn't tenable--I'm just poking around.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: nfs4trace -- a DTrace provider for NFSv4
* Rich Teer <[EMAIL PROTECTED]> [2006-03-06 15:58]: > On Mon, 6 Mar 2006, Sam Falkner wrote: > > Community could be either NFS or DTrace; perhaps it should be independent, > > since it spans both. I expect both communities to affiliate with the > > project, > > if it gets approved. > > If it had to belong to one community, I think DTrace would be more > appropriate. Happily, there are no such restrictions; a project can be endorsed by multiple communities (or none). Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Using different swap devices for different projectids...
* Roland Mainz <[EMAIL PROTECTED]> [2006-03-07 02:04]: > Is it currently somehow possible to assign processes running under one > projectid to one specific swap device and others to another set of swap > devices ? > The scenario would be a machine shared by two workgroups (all memory > slots full) and one of them bought a set of solid-state disks to be used > as swap device. However the usage of these extra swap devices should be > restricted to a specific set of processes (for example running under a > specific projectid) to avoid that swap activity generated by normal > processes reduces the throughput of the priviledged processes... > ... can that somehow be done ? Not yet. This idea has been discussed as part of possible extensions to resource management; once Steve has his umbrella alias up, I'd reraise it there. It's needed to provide resource isolation for zones as well... - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal: lofi [ compression & encryption ]
* Darren J Moffat <[EMAIL PROTECTED]> [2006-03-08 04:32]: > OpenSolaris has the lofi(7d) driver that allows you to use a file > in a filesystem as a block device. > > Over in the Security Community you will see some info that some of > us have created some crypto support for lofi(7d), though we have > been slack on posting the code. Belenix has compression support > for lofi(7d) as well. > > I'd like to propose an new project so that we can merge both of > these technologies together and integrate them into OpenSolaris > proper. > > Project Name: > loficc [lofi compression & cryptography support ] > > Project Description: > > Add compression and encryption support to lofi(7d) and lofiadm(1m). > > Project alias: yes please <[EMAIL PROTECTED]> Seconded. -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Has OpenSolaris' code ever been checked with tools such as Coverty ?
* Yann POUPET <[EMAIL PROTECTED]> [2006-03-09 09:33]: > Hello, > > I don't know if this is the right place for this question, I hope so ... > > I was just wondering if OpenSolaris' code has ever been checked/audited with > tools that attempt to discover bugs, such as Coverty. > > http://scan.coverity.com/ > > There may be some other similar tools, and it could be interesting to check > Solaris, couldn't it ? I believe we have engaged Coverity for a scan recently. One of the more theoretical reasons for pursuing a GCC clean build (for ON) was to enable the use of such tools easily; the tools-gcc (on the general tools-discuss list) would be a good place to discuss further. I know I've looked at smatch.sf.net as one interesting utility of this kind... - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Fresh man from ShenYang China
* Zhigang Yao <[EMAIL PROTECTED]> [2006-03-14 05:46]: > I want to attend into the Open Solaris Projects.But,I am a fresh > man.So I have a simple problem---What can i do for this?Hope > reply.Thank you. Once you have a system installed with a distribution, you can examine the current "introductory" bugs http://www.opensolaris.org/os/bug_reports/oss_bite_size/ You can then discuss these on opensolaris-code@opensolaris.org, or just start working. At some point, you'll have a proposed fix for one or more of them, and can ask on [EMAIL PROTECTED] for help in getting your fix integrated. Alternatively, you could join one of the projects or communities working in an area you find technically interesting. The more experienced developers in those groups may have ideas for introductory work in the area. Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
* Nils Nieuwejaar <[EMAIL PROTECTED]> [2006-03-16 10:49]: > We would like to propose a solaris-internals community. The initial > leaders would be Jonathan Chew, Eric Lowe, Eric Saxe, and me. We hope to > expand this list quickly, with engineers from inside of Sun and from the > community. > > There are quite a few communities dedicated to specific parts of Solaris, > but none dedicated to Solaris as a whole. There is no single place where > people can go for technical information about Solaris. The existing > general OpenSolaris discussion groups are focussed primarily on OpenSolaris > distribution, building, an usage issues, rather than on low-level technical > details. > > The solaris-internals community would host one or more discussion groups. > Initially there would just be a single group: solaris-internals. If the > traffic warranted, we could create more specific discussions within the > group. Some possible child discussions might be solaris-internals-newbies, > solaris-internals-vm, solaris-internals-scheduling, etc. > > This group would serve as a repository for design documents that do not > fall into one of the existing communities. This documents would cover both > new projects as well as whatever historical information we can get > clearance to publish. By acting as a central repository, this group would > provide a way for engineers to make technical information publicly > available without requiring them to undertake the responsibility of > creating and maintaining their own communities. > > If the group prospers, would could propose folding some of the less active > technical communities into it, reducing the proliferation of specialized > communities. I believe this proposal needs to provide further contrasts against existing communities and projects to make aspects more clear. (As a nit, the bare word "solaris" is not an appropriate part for a community name. I'm also not sure that "opensolaris" is better, as there are many participating technologies in OpenSolaris as a whole that could reasonably claim to have meaningful "internals".) 1. What is the relationship between this community and existing, demonstrably technical communities, like the networking, zones, and zfs communities? 2. What is the relationship between this community and the existing ON (Nevada) community? Why is that alias, or a second alias (or project) not appropriate for hosting this content? (Why not [EMAIL PROTECTED]) 3. What is the relationship between this community and the existing opensolaris-code and opensolaris-rfe aliases (which are discussing technical topics regarding ON components)? 4. We're examining communities commenting on new community proposals and community-to-project demotion processes on cab-discuss; no aspect of that discussion really suggests that one community should propose its existence based on the subsumption of others. I certainly don't think that that's a suitable mechanism for the alleged proliferation problem. Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
* Nils Nieuwejaar <[EMAIL PROTECTED]> [2006-03-16 12:37]: > On Thu 03/16/06 at 11:30 AM, [EMAIL PROTECTED] wrote: > > 2. What is the relationship between this community and the existing ON > > (Nevada) community? Why is that alias, or a second alias (or > > project) not appropriate for hosting this content? (Why not > > [EMAIL PROTECTED]) > > The Nevada community seems to be shooting for a C-team kind of function, > while we are trying to get to more of an I-team level. Also, we want to > pull in historical information to help explain how we got to this point, > which would seem inappropriate for a Nevada-specific group. But appropriate for an ON community. That is, if the current ON community were refined, such that its long-running aspects were the community focus and its specific release were a project (or at least separated), then the distinctiveness of internals is lessened. Have you talked with the current ON community leads to understand why they couldn't accommodate a modification that admits one or more of the internals proponents as a lead. This would address Eric's point of > Beyond the discussion list we want to build a community page to > capture system internals documentation and provide a one-stop shop > for system internals (aside from buying the book). although that would also come from being a separate project endorsed by the ON community. > > 3. What is the relationship between this community and the existing > > opensolaris-code and opensolaris-rfe aliases (which are discussing > > technical topics regarding ON components)? > > [Reasonable responses elided.] My concern here was more connected with the fact that these "grandfathered" aliases exist and overlap (to whatever degree). I think I would like to hear about how to eventually close some of the program-wide aliases, as consolidations and communities evolve their own code submission discussions. * Eric Lowe <[EMAIL PROTECTED]> [2006-03-16 14:02] > Networking, zones, zfs, etc. are focused on specific areas of the > system, and a good portion of their discussion (the vast majority in > fact) centers around learning about or using the specific features > rather than learning about the nitty-gritty technical details. > > We want to create a forum which is 100% purely technical in nature. > > > 2. What is the relationship between this community and the > > existing ON (Nevada) community? Why is that alias, or a > > second alias (or project) not appropriate for hosting this > > content? (Why not [EMAIL PROTECTED]) > > Same argument as above. Since the "having a web page" requirement is satisfied by at least two alternatives, I'm assuming that the argument you [Eric] mean is "we don't fit into the current ON community because we're more technical". If you've already spoken with the current leads, do they agree that the community cannot expand to allow this area of discussion to fit? > The communities which exist today have their place because there are > aspects around learning about and experimenting with new features. > > Continuing down that path without providing a more general technical > forum means that if I want to keep up on the state of the art of the > system internals, I have to drown in non-technical information and > discussion. Linux, NetBSD, FreeBSD, and others have kernel discussion > lists for this reason. Near fatal mail immersions aside, I think my concern is that this community proposal appears to be satisfied by the expansion of the current coverage of the ON community's discussions, as additional content pages and discussion forums within that community, or as a project endorsed by that community (and perhaps others). It's difficult to envision the potential future contributors of this community, particularly given (out of context, but in support of my point) > We want to create a forum which is 100% purely technical in nature. as being substantially distinct from, although perhaps smaller than, the future contributors to a specific release from the ON community. That is, it feels like a subset. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
* Stephen Hahn <[EMAIL PROTECTED]> [2006-03-16 14:19]: > My concern here was more connected with the fact that these > "grandfathered" aliases exist and overlap (to whatever degree). I > think I would like to hear about how to eventually close some of the > program-wide aliases, as consolidations and communities evolve their > own code submission discussions. This paragraph ended up being more ambiguous than I would like. Resolving the future of these aliases does not need to be addressed by the makers of the proposal; I was merely anticipating that this set of forums may become redundant, if more code-oriented forums arise. - Stephen ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris-{code, rfe, bugs} (was Community proposal: solaris-internals)
* Eric Lowe <[EMAIL PROTECTED]> [2006-03-17 11:21]: > Al Hopper wrote: > >On Thu, 16 Mar 2006, Mike Kupfer wrote: > > > >>I think opensolaris-code can just go away. It was originally created > > > >Agreed. > > > >>during the Pilot program, when there was a single consolidation and a > >>lot fewer people. When I proposed it, I thought of it as a stopgap > >>measure to deal with the high traffic, much of it non-technical, on > >>opensolaris-discuss. Now that we have multiple consolidations, each > >>with (at least) its own "discuss" list, and a whole lot more people, > >>opensolaris-code serves only to confuse people about where they should > >>post. > >> > >>I'd like to see opensolaris-bugs and opensolaris-rfe go away, too. Bugs > >>and RFEs should get posted to the bug database, not mailing lists. > > > >And they can be discussed on opensolaris-discuss@opensolaris.org, if > >necessary. > > It sounds like we have agreement that opensolaris-code, opensolaris-bugs, > and opensolaris-rfe should go away. > > Who will take ownership of this and make it happen? Someone on the infrastructure team can develop a public procedure for shutting down a list. This procedure will then get OGB blessing, and be carried out for each of the above lists. I'd also be happy to see draft process submissions from non-infrastructure folks for this or any other community-change-event. As an example, I sent http://www.opensolaris.org/jive/thread.jspa?threadID=6569 to start working on the community demotion problem. The next step for that process is for it to get some proposed timescales, and then to get the OGB to move to adopt it for use. (In case it's not apparent, I really prefer operating under consensus-oriented processes.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris-{code, rfe, bugs} (was Community proposal: solaris-internals)
* Ignacio Marambio Cat?n <[EMAIL PROTECTED]> [2006-03-17 12:04]: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > > > Someone on the infrastructure team can develop a public procedure for > > shutting down a list. This procedure will then get OGB blessing, and > > be carried out for each of the above lists. I'd also be happy to see > > draft process submissions from non-infrastructure folks for this or > > any other community-change-event. > > > > As an example, I sent > > > > http://www.opensolaris.org/jive/thread.jspa?threadID=6569 > > > > to start working on the community demotion problem. The next step for > > that process is for it to get some proposed timescales, and then to > > get the OGB to move to adopt it for use. (In case it's not apparent, > > I really prefer operating under consensus-oriented processes.) > > > > - Stephen > > What would happen to the mails in the mailing lists belonging to each of > the defunct communities/projects? > while the communities/projects are not important, the mails certainly > are and should remain accessible somehow. There is no intention to delete any content from web trees or email/forum postings. > regarding to the remotion process, i think it's ok Cheers Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: opensolaris-{rfe, bugs} bugs} (was Community proposal: solaris-intern
* Peter Tribble <[EMAIL PROTECTED]> [2006-03-18 09:45]: > I don't agree that opensolaris-rfe and opensolaris-bugs should go away. > > At least, not yet. > > The problem is that the current bug/rfe submission process is - frankly - > awful. > Submitting a bug past the nit-picking input validator is bad enough, trying to > put in an rfe is very difficult. To be honest, mentioning something on a > mailing > list and getting someone inside Sun to pick it up and log it is a *very* much > better way to get issues logged. > > As such, can we please either (a) make the current bug/rfe submission page > actually work in a user-friendly manner, or (b) scrap it and make the mailing > lists > the places to submit issues. We're going to fix the current page (or reimplement it so that we can fix it)--we have to keep the basic aspects of submission on a path to being fully automated. Suggestions for relaxing any particular nit-picking are encouraged. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: "-xstrconst" patch / was: Re: [osol-discuss] Footprint: Compiling kernel+tools with "-xstrconst -xbuiltin=%all"
* Joerg Schilling <[EMAIL PROTECTED]> [2006-03-20 13:36]: > Keith M Wesolowski <[EMAIL PROTECTED]> wrote: > > "The list of code reviewers should be individuals who have > > actually reviewed the code, not an alias for a group of people who > > were given the opportunity to do so." > > This reminds me of to ask when code review will be possible by people > from outsude Sun. Can you be more specific about what kind of code review actions you mean? For instance, wearing my RTI advocate hat, I would probably accept RTI submissions received from sponsors that had external code reviewers today (and subsequent days, too). Is that what you mean? - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [tools-discuss] Distributed source code management selection, draft
* Holger Berger <[EMAIL PROTECTED]> [2006-04-07 18:12]: > On 4/8/06, Al Hopper <[EMAIL PROTECTED]> wrote: > > On Fri, 7 Apr 2006, Stephen Hahn wrote: > > > > > > > > Commentary is encouraged. We can start to look at specific > > > SCM-dependent tools next week, unless we are more distant from > > > consensus that I believe... > > > > > > Enjoy the weekend; my thanks to all. > > > > ... snip > > > Therefore, we have decided to select Mercurial as the DSCM for > > > OpenSolaris. In the coming time, we hope to work with the Mercurial > > > community to address any issues we may find while integrating > > > Mercurial into the OpenSolaris repository framework and converting > > > existing source bases to use it. > > . snip > > > > Indeed. Many well-earned Thanks to all who participated in the SCM tool > > selection and to Stephen Hahn for taking the lead role. > > > > I think that Mercurial is the worthy winner of the evaluation. > > May I ask whether this decision is wise? What is the background to > prefer Mercurial over bit keeper, git or subversion? This decision was made methodically, by defining requirements, executing the tools considered, examining their communities, and soliciting feedback from all members of the community. > My primary concerns about using Mercurial as future basis for > OpenSolaris development are: > - Interoperability: Is there a compatibility layer or bridge to make > the Mercurial repository available to CVS or Subversion clients? Many > tools require either CVS or Subversion and Mercurial seems to provide > no such access. The plan of record for hosting source code is to support Subversion and (now) Mercurial as a per-repository choice, so there's no freeze out for projects that believe they require Subversion for their tools. The primary consolidation driving the distributed SCM choice is ON; there are no tools constraints of the kind you mention upon contributors to ON. > - Portability: On how many platforms does Mercurial actually run? If I > recall it correctly Mercurial required Python(!!) which is a > portability NIGHTMARE. Mercurial was under discussion for other > projects including KDE and was dismissed due to such problems. Portability to platforms other than OpenSolaris based distributions was not a requirement. I am unfamiliar with the portability issues you raise regarding Python. > - Availability: Neither Suse Linux or any BSD variants (FreeBSD, > OpenBSD, NetBSD) provide Mercurial packages as part of their > distributions. Choosing a niece product may not be wise. git, > Subversion and bitkeeper are not only more popular - they are also > much more widespread and better tested than Mercurial thanks to the > far larger community. Again, ON consolidation development on other platforms was not a requirement. Of the list you mention, BitKeeper is not OSS (Requirement E0) and Subversion is not distributed; git was evaluated as a part of this effort. Results of the evaluation are available on the Tools community web tree: http://opensolaris.org/os/community/tools/ One of the upcoming submissions for the freeware consolidation will be to ensure that Subversion and Mercurial are available in one or more of the standard installation scenarios. Thanks for the feedback. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Main OS/Net repository - based on "Subversion" or "Mercurial" ? / was: Re: [osol-discuss] Re: [tools-discuss] Distributed source codemanagement selection, draft
* Roland Mainz <[EMAIL PROTECTED]> [2006-04-09 18:06]: > Stephen Hahn wrote: > > The plan of record for hosting source code is to support Subversion > > and (now) Mercurial as a per-repository choice, so there's no freeze > > out for projects that believe they require Subversion for their tools. > > The primary consolidation driving the distributed SCM choice is ON; > > there are no tools constraints of the kind you mention upon > > contributors to ON. > > What does that mean for "ON" - will the main OS/Net repository on > opensolaris.org be based on Subversion or on Mercurial ? The writeable-to-committers repository will be a Mercurial repository. We have suggested that we would make a read-only SVN repository available earlier on opensolaris.org--depending on a couple of factors, we may have read-only repositories in both "formats" for an interim period. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Program technical status, 11 April
deployments, there are a number of opensolaris.org software components that I would like to host, pretty much immediately: we need to improve many aspects of the site, including voting support for the OGB election, code review notifications, per-user repositories, and community, project, and user file management. Plus we could really use some new pictures for the front page. For all these developments, I expect website-discuss and tools-discuss to be the primary mailing lists. Please join in. As always, please share your concerns; I am happy to receive them privately or on the list. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal -- Honeycomb Information and dev tools
* Peter Buckingham <[EMAIL PROTECTED]> [2007-01-30 10:28]: > I guess the decision the Open Solaris community needs to make is if it > is about building developer communities for Solaris-based appliances, or > if there is a more appropriate place to do this... I don't have an opinion on the surprisingly strong reactions to a project proposal, but I do know that http://opensolaris.org/os/community/appliances/ would be an appropriate group for exploring how Honeycomb ideas and technology might become an open source effort. - Stephen * I do think that the expectation that every project on opensolaris.org has their act together, and meets some (apparently high) standard of exposure and completeness, is bound to lead to disappointment. Perhaps it would be more useful to figure out how to highlight the projects that we admire, and let the nascent ones use the tools we have to grow into something more complete... -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project Proposal -- Honeycomb Information and dev tools
* Darren J Moffat <[EMAIL PROTECTED]> [2007-01-31 02:53]:
> Peter Buckingham wrote:
> >Hi All,
> >
> >Honeycomb is a unique archival storage product developed within Sun. It
> >is built upon a clustered system and provides strong reliability
> >guarantees for it's data storage (Write-Once, Read Many) and metadata.
> >
> >We (the development team) would like to start to provide information
> >about the system. The intention is to make it significantly easier for
> >people to start developing applications with Honeycomb in mind and to be
> >able work with people on developing Solaris appliances.
> >
> >The intention is to initially put up the whitepaper and some
> >documentation to be followed by the SDK and Honeycomb emulator.
>
> What about source code ? I think for this to be an OpenSolaris project
> I'd want to see source. OpenSolaris isn't a general Sun site for all stuff.
>
> Unless you are going to provide the source code for Honeycomb under an
> OSI approved license *and* the intent is this becomes part of
> OpenSolaris distributions then it is '-1' from me. This isn't the
> appropriate hosting site.
Doesn't an OpenSolaris-based appliance constitute a distribution in
some form? I agree with the "must have source" bit, but I think if
you mean that all projects must target one or more of {Belenix,
Martux, Nexenta, Schillix, Solaris}, then I believe that to be too
severe.
I am hoping that the Appliance Core Contributors will have some
feedback for this discussion in a week or two.
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED] http://blogs.sun.com/sch/
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: [Fwd: Re: GPLv3?]
* Shawn Walker <[EMAIL PROTECTED]> [2007-02-01 07:52]: > > Nobody likes the closed_bins; but it's not under our > > control > > I think what's most frustrating about the closed_bins is that we don't > know *why* in some cases. It would be helpful if there were a status > list for the closed_bins that indicated what items would never be > available (due to 3rd party or something generic like that as reason), > which have a chance of being available at some unknown date (under > review), and which items will be available at some unknown date (in > process). > > That would go a long way to silencing critics. If we *knew* that you > actually couldn't release an item ever because it was completely out > of "SUN's hands" so to speak; that might be a motivation for people to > start working on something. At the moment, we have some vague notion > that some things are "out of our control" but we don't know who the > group of people the comprise "our" is, and we don't know if that means > *forever*. > > I apologise if this information is somewhere obvious and I've missed > it. > > Thankfully though, we finally *know* that libc_i18n is completely out > of "SUN's hands" so to speak. It indeed sounds like a great > opportunity for a community project. If a contract carries terms of confidentiality or non-disclosure, then the signatories can't tell a third party the specific details you seek. I suppose my question is: why not just assume that a non-SMI-led effort to provide an OSS replacement for each and every closed binary is needed, and then order them by interest, necessity, or some other priority? For each consolidation publishing closed binaries, you have a list. Start the projects to reduce the reliance or inclusion of encumbered components. As a non-lib example, for instance, it's been suggested that ON be scrubbed of its ksh88+smi scripts--replaced with tested ksh93-based versions. This means that distributions would be less affected by restrictions around ksh88+smi binary distribution. (That's a shell scripting project, which probably has the opportunity to also look at identifying common shell scripting style and practice for ON or other consolidations (if the hypothetical project team were interested).) Similar cases can be made for other encumbered components. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: [Fwd: Re: GPLv3?]
* Mike Kupfer <[EMAIL PROTECTED]> [2007-02-01 11:05]: > >>>>> "Shawn" == Shawn Walker <[EMAIL PROTECTED]> writes: > > Shawn> It would be helpful if there were a status list for the > Shawn> closed_bins that indicated what items would never be available > Shawn> (due to 3rd party or something generic like that as reason), > Shawn> which have a chance of being available at some unknown date > Shawn> (under review), and which items will be available at some unknown > Shawn> date (in process). > > http://www.opensolaris.org/os/about/no_source/ > > Probably ought to be linked to from the General FAQ > (http://www.opensolaris.org/os/about/faq/)...? It already is, under the question "What source code does the OpenSolaris project include?". - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Project Proposal -- Honeycomb Informationand dev
* Scott Tracy <[EMAIL PROTECTED]> [2007-02-01 22:07]: > So, let's talk through this so I can understand. How would you work > on a design doc with the community? Walk through the normal SDF > process on something you want to develop from start to finish in the > open. I don't think it's necessary to walk through the entirety of the software development framework (SDF) to answer your question. I think that what's emerging (for me) from this discussion is that there is a desire for a OpenSolaris project proposal to follow some amount of discussion in related community groups (via forum, or via IRC maybe). That is, the speculative phase of a project--between one pager (internal announcement) and first design review--should take part, at least in part, in a sponsoring community group first. Once it becomes clear that the initial idea has garnered some interest (or bemused tolerance), then a project proposal to -discuss is easily justified. The particular project here has a luxury of community groups to choose from: appliances, storage, and databases. If none of these community groups is responsive, that's useful feedback to the OGB, since active community groups are the backbone of the current draft constitution. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project Proposal -- Honeycomb Information and dev tools
* Darren J Moffat <[EMAIL PROTECTED]> [2007-02-06 09:40]: > Stephen Lau wrote: > >Darren J Moffat wrote: > >>Eric Boutilier wrote: > >>>Some people have asserted or implied that although support for this > >>>proposal is not easily discernable, nevertheless it is there, and > >>>therefore the proposal passes per current policy. > >>> > >>>I agree and think we should move it along, which means that the > >>>next step is a post (by me, as usual) acknowledging that the > >>>proposal has been seconded, followed by initiating the project web > >>>space. > >>> > >>>Any objections? > >> > >>given that there were objections and suggestions for using an existing > >>community how do we deal with that ? > >> > >>I think what you are saying is that as long as there is one +1 it > >>cancels all -1's, that just isn't fair. > > > >But that's the current project approval policy, for better or for worse. > > Personally I see that there is no point in the approval policy as it > stands because it doesn't count anything but positive comments if the > original submitter sticks to their proposal and > > >Ben Rockwood and I have been bouncing back ideas for a new project > >approval policy.. I'll try to send it out today. > > Great. A simple sum would do the trick for me as an improvement over > what we have, ie if there are more +1's than -1's the pluses win. I'm > sure there could be some further improvement though that gave some > better weight based on input from community leaders where the project > would line up with (if any existed). > > I'm not trying to put up barriers to projects but if there is no way an > objection can be raised that has an impact we might as well change > direction and not have any "seconding" procedure at all and have project > creation completely automatic. Which might be a good thing. The initial project proposal process was written to generally allow projects that had more than one interested individual, and was appropriate when we didn't know what a project should be; I think Ben and Steve's idea to refine it, now that we're further along, is a good one. Certainly your idea of requiring a majority would be something for them to consider. At times, I know Ben supported the idea that a project actually garner an initial sponsoring community group. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: What does OpenSolaris Success look like to you?
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-02-07 09:04]: > When the community controls this, it will be the community volunteers > who will carry more of the burden; what we're doing is quite unique: > continue to develop an OS while opening up the development process > and the source code management system. I'm not sure how we could > approach this much differently. I think this point is worth emphasizing: part of the argument to make the source open and the development process open was that the development would continue--that we wouldn't stand still on whatever base of code we had and all navel-gaze and contemplate perfect tools and so forth. Progress has been made on all of Roy's points, for many of the consolidations; some of the slowness have been because of mistakes or misinvestments by me, but much of it is because stopping development was not considered a serious choice. (Put another way: if you've liked a feature since, oh, onnv_18, you probably have unconscious reservations about a 100% focus on culture change.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Request a new Community for License Discussion (was CAB/OGB Position Paper # 20070207)
* Ghee Teo <[EMAIL PROTECTED]> [2007-02-12 13:16]: > Simon Phipps wrote: > >I'd suggest that, as we have a member-based system emerging right now, > >maybe we should have a list as Roy suggests that's writable only by > >Core Contributors (readable by all). Time for an "opensolaris-core" > >list perhaps, a place for substantive discussion of issues facing the > >community, and hustings for the forthcoming elections > > Thus open up another question, who is qualified to be a member. Do we > have on a set of subjective of contribution criteria which are encompassing > more than just engineers? Can the membership be reviewed and approved by > leaders and its appointed subcommitee of each of the OpenSolaris > communities. Core Contributors, the only voting member class, are proposed by each Community Group. As such, Community Groups like Marketing are permitted (and expected) to have different criteria--I hope involving an equivalent amount of time or energy--suited to the activities that each Community Group sponsors. The Board would only step in in the case of inactivity or abuse of Community Group privilege. (Please consider reading the draft Constitution.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Request a new Community for License Discussion (was CAB/OGB Position
* Ghee Teo <[EMAIL PROTECTED]> [2007-02-13 07:58]: > Shawn Walker wrote: > >> Cool, and where is the draft constitution? > > > >I suspect you're looking for this: > > > >http://www.genunix.org/wiki/index.php/OpenSolaris_Governance_Draft_03 > > YES. Thanks! I will read that. I also realised this morning that many > things have been discussed in cab-discuss which many on this list do > not subscribe to naturally. I fear many are left out and to see > 'rock' start like Roland Mainz :) has to explicitly requesting to be > added to the core contributor list just simply WRONG in the > formulation of the membership list :/ The current approach is that projects seek sponsoring Community Groups, and that project leads will become Contributors or Core Contributors in the sponsoring Community Group. The pursuit of sponsorship is open to either a project or a Community Group. > What can we do complete the list of contributors as broad yet with > reasonable accuracy? We don't want to swamp Stephen Hahn with > hundreds of email request, or do we :)? I would rather be swamped than get nothing. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Request a new Community for License Discussion (was CAB/OGB Position
* Alan Coopersmith <[EMAIL PROTECTED]> [2007-02-13 08:54]: > Ghee Teo wrote: > >I fear many are left out and to see 'rock' start like Roland Mainz :) > >has to explicitly > >requesting to be added to the core contributor list just simply WRONG in > >the > >formulation of the membership list :/ > > The problem that caused Roland to be left out is that "contributors" are > associated with/nominated only by communities, not projects, and most of > Roland's work has been with projects (especially ksh93-integration). > > It does seem strange if we're trying to capture the list of those doing > the most work to exclude the mechanisms set up to organize work (projects). The present form makes pursuit of Community Group sponsorship and Contributor status up to the project leads. Failures to match up sponsorship may have multiple causes, with appeal to the Governing Board as a fallback. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Request a new Community for License Discussion (was CAB/OGB Position
* James Carlson <[EMAIL PROTECTED]> [2007-02-13 09:36]: > Stephen Hahn writes: > > The current approach is that projects seek sponsoring Community > > Groups, and that project leads will become Contributors or Core > > Contributors in the sponsoring Community Group. > > That doesn't happen, though. Not yet, no: my first excuse is that we're in the bootstrap phase of the process. But even during the bootstrap, people have recourse to the Board. I suppose the priority that I am operating with (divined from the Board, I think) is that we need an elected Board with a clearer mandate to make changes. First on that set of changes (I hope) is some reeducation of what it means to have a Community Group--it's not just a set of web pages and an alias, but a responsibility to act as the embassy for a set of technical or social interests to the larger Community. That is, it's work, which I don't think was made clear during the earlier phases of the effort. (But in all of the current development process, the onus is on the individual or group suggesting change... so we're at least consistent. :) ) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris stablization builds
* Adam Leventhal <[EMAIL PROTECTED]> [2007-02-14 00:24]: > On Tue, Feb 13, 2007 at 11:15:56PM -0800, Joe Little wrote: > > The recent fix-only release of B54 and B55 were a breath of fresh air. > > We utilize OpenSolaris builds in one fashion or another in production > > both at Stanford in my role there as well as where I consult for use > > in file servers. Again, I look upon recent features, fixes, and I'd > > like to jump to newer releases. However, at the same time I see a lot > > of churn and potentially unstable putbacks that just need a bit more > > time to flesh out. > > > > It would be great if OpenSolaris as a whole went through regular > > stabilization builds or otherwise followed a scheme whereby those in > > production or quasi-production modes may feel safe in adopting series > > of builds most likely not to give them unwanted headaches and also > > improve upon previous builds in their infrastructure. > > That sounds like a great idea especially for people who are planning on > deploying Solaris Nevada or building software solutions out of it. Would > it be sufficient to have, say, two builds of stabilitzation every 3 months > or so? At the beginning of January, we talked a bit about this on opensolaris-code. See http://www.opensolaris.org/jive/thread.jspa?threadID=21240&tstart=50 and associated references and replies. I am trying to push the consensus there into the build schedule. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris stablization builds
* Stephen Lau <[EMAIL PROTECTED]> [2007-02-14 09:05]: > Joe Little wrote: > >The recent fix-only release of B54 and B55 were a breath of fresh air. > >We utilize OpenSolaris builds in one fashion or another in production > >both at Stanford in my role there as well as where I consult for use > >in file servers. Again, I look upon recent features, fixes, and I'd > >like to jump to newer releases. However, at the same time I see a lot > >of churn and potentially unstable putbacks that just need a bit more > >time to flesh out. > > > >It would be great if OpenSolaris as a whole went through regular > >stabilization builds or otherwise followed a scheme whereby those in > >production or quasi-production modes may feel safe in adopting series > >of builds most likely not to give them unwanted headaches and also > >improve upon previous builds in their infrastructure. > > http://blogs.sun.com/sch/entry/opensolaris_restricted_builds_through_the > > there used to be purty graphics with that post, but i'm not sure what > happened to 'em. They're back. The server hosting the images had a brief outage earlier today. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SPAM-Attack via Jive (AGAIN) ... / was: [Fwd: [ksh93-integration-discuss] For sale:Nokia n95:$300, Nokia n93:$230]
* Roland Mainz <[EMAIL PROTECTED]> [2007-02-18 15:10]: > Is there a way to prevent things like the posting below ? For example is > it possibe to reconfigure Jive to allow postings only for people who are > subscribed to that list or make sure that such postings are queued for > moderation by the list admins automatically ? Not easily, no. I'll look at the moderation idea, but the "subscribers only" request contradicts the aims of most legitimate forum posters. - Stephen ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: SPAM-Attack via Jive (AGAIN) ... / was: [Fwd:
* Richard L. Hamilton <[EMAIL PROTECTED]> [2007-02-20 21:41]: > I still think feeding the lists to a dedicated news server could be the > cleanest approach to providing a way to read the messages by list in > a threaded manner. Either the groups could be read-only, or (my preference, > since I'd rather not use an email interface for something like this) they > could be auto-moderated (must be able to be associated with a registered > email address), or else the server could require authentication (with one's > os.o account and password, I suppose). Is there an NNTP server that offers this sort of posting policy? > That would IMO be a lot cleaner, and more scalable (even a wimpy news > server can probably handle more messages per day than the opensolaris.org > lists are ever likely to see). And with reasonably fast clients that > can be configured to cache headers (I like knews, myself), it can be much > better performing for people with relatively slow network access (which > could be common with worldwide participation). Or if enough folks can't > resist the temptation to post HTML, Thunderbird or Mozilla would probably > be ok too. Although it's not high on my infrastructure list (which is mostly about development and governance at the moment), I don't have a problem with running a news server eventually. (I am nervous about running news, mail, and web forums in fully gatewayed fashion, however...) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Laszlo (Laca) Peter <[EMAIL PROTECTED]> [2007-02-22 18:29]: > So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the > reason for defining /usr/gnu wasn't theoretical -- it allows moving > GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us > integrating more GNU packages into Solaris. We have already seen > the first few putbacks (m4, bison). > > The JDS team (well, Dermot ;) is working on adding more packages > (mostly the tools required for building JDS). Obviously, it's easier > for us to deliver these through the JDS consolidation. However, they > really don't belong there. Neither do some of the packages we already > deliver into Solaris, like Python, libpng, libogg, etc. > > I think the GNU Solaris community would be a perfect place for these, > if it wasn't a community but a project (or a consolidation?). > I propose that we launch a project that aims for creating a repository > of spec files that follow the /usr/gnu rules. Sun could pick the > packages that we want to integrate into Solaris and support, other > packages could be available from opensolaris.org with community support > only. > > How does this relate to: > > SFW: If proven successful, it would gradually phase out SFW. The idea > is that this repository would be more inclusive (i.e. not only > supported Solaris packages) and easier to contribute to than SFW. > > CCD: Again, if proven successful, supersedes it. One big difference is > that the CCD installs to /opt, while this repository would install > to /usr. > > SFE: We have 200+ spec files written by various Sun and non-Sun opensolaris > community members here: > http://pkgbuild.svn.sf.net/viewvc/pkgbuild/spec-files-extra/trunk/ > Those that satisfy the /usr/gnu criterion of being listed in > the FSF/UNESCO free software directory can be moved into the > new repository (after some clean-up and testing). I'm puzzled why it wouldn't be appropriate to just adjust SFW to take either classic-SFW or pkgbuild spec files as part of its build process. There's a project, a C-team with knowledge about freeware dependencies (that I'm sure would be happy to take on members), and an ongoing effort to change its processes. That is, why not just merge CCD, SFE, and SFW into a "freeware" consolidation that delivers appropriately to /usr, /usr/gnu, and elsewhere, and allow multiple build approaches? (Just, please, don't tell me you wanted to avoid discussions that might involve compromise...) - Stephen ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Eric Boutilier <[EMAIL PROTECTED]> [2007-02-23 09:56]: > On Fri, 23 Feb 2007, Stephen Hahn wrote: > >* Laszlo (Laca) Peter <[EMAIL PROTECTED]> [2007-02-22 18:29]: > >>So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the > >>reason for defining /usr/gnu wasn't theoretical -- it allows moving > >>GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us > >>integrating more GNU packages into Solaris. We have already seen > >>the first few putbacks (m4, bison). > >> > >>The JDS team (well, Dermot ;) is working on adding more packages > >>(mostly the tools required for building JDS). Obviously, it's easier > >>for us to deliver these through the JDS consolidation. However, they > >>really don't belong there. Neither do some of the packages we already > >>deliver into Solaris, like Python, libpng, libogg, etc. > >> > >>I think the GNU Solaris community would be a perfect place for these, > >>if it wasn't a community but a project (or a consolidation?). > >>I propose that we launch a project that aims for creating a repository > >>of spec files that follow the /usr/gnu rules. Sun could pick the > >>packages that we want to integrate into Solaris and support, other > >>packages could be available from opensolaris.org with community support > >>only. > >> > >>How does this relate to: > >> > >>SFW: If proven successful, it would gradually phase out SFW. The idea > >> is that this repository would be more inclusive (i.e. not only > >> supported Solaris packages) and easier to contribute to than SFW. > >> > >>CCD: Again, if proven successful, supersedes it. One big difference is > >> that the CCD installs to /opt, while this repository would install > >> to /usr. > >> > >>SFE: We have 200+ spec files written by various Sun and non-Sun > >>opensolaris > >> community members here: > >> http://pkgbuild.svn.sf.net/viewvc/pkgbuild/spec-files-extra/trunk/ > >> Those that satisfy the /usr/gnu criterion of being listed in > >> the FSF/UNESCO free software directory can be moved into the > >> new repository (after some clean-up and testing). > > > > I'm puzzled why it wouldn't be appropriate to just adjust SFW to take > > either classic-SFW or pkgbuild spec files as part of its build > > process. There's a project, a C-team with knowledge about freeware > > dependencies (that I'm sure would be happy to take on members), and an > > ongoing effort to change its processes. > > > > That is, why not just merge CCD, SFE, and SFW into a "freeware" > > consolidation that delivers appropriately to /usr, /usr/gnu, and > > elsewhere, and allow multiple build approaches? > > > > (Just, please, don't tell me you wanted to avoid discussions that > > might involve compromise...) > > > In other words, adjust the opensolaris.org sfwnv project to be a repository > that implements multiple build systems, and that feeds into the the Nevada > SFW and JDS consolidations and the Solaris 10 Companion CD. > > That does seem to make more sense. I don't think I'd force any consolidations together. JDS functions quite well, in my opinion. The CCD, on the other hand, has served its purpose and (for Solaris) a reexamination of its role vis-à-vis SFW and JDS is probably overdue. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Laszlo (Laca) Peter <[EMAIL PROTECTED]> [2007-02-23 10:10]: > On Fri, 2007-02-23 at 09:36 -0800, Stephen Hahn wrote: > > That is, why not just merge CCD, SFE, and SFW into a "freeware" > > consolidation that delivers appropriately to /usr, /usr/gnu, and > > elsewhere, and allow multiple build approaches? > > Knowing both build approaches, I simply don't see how you can > merge 2 vastly different build systems into a coherent system. Umm, make drives feature-level build dependencies, pkgtool builds individual packages, both toolsets install their packages (and test package dependencies) against an alternate root? That is, SFW gives up the notion of separated proto area and package build phases, and pkgtool doesn't use its .spec dependency evaluation as part of the build. SFW and pkgtool policies on pulling versus keeping a static copy of upstream sources will have to be reconciled; there are a couple of choices here. I'm sure there are other issues, but I don't think it's unprecedented complexity by any means. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: "Shells&&Utilities" community ? / was: Re: [osol-discuss] /usr/gnu project?
* Roland Mainz <[EMAIL PROTECTED]> [2007-02-22 18:39]: > "Laszlo (Laca) Peter" wrote: > > So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the > > reason for defining /usr/gnu wasn't theoretical -- it allows moving > > GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us > > integrating more GNU packages into Solaris. We have already seen > > the first few putbacks (m4, bison). > [snip] > > What about creating a "Shells&&Utilities" community as umbrella for the > ksh93-integration, shells and the /usr/gnu/ project (with > [EMAIL PROTECTED] being the main list for now) ? That would > cover most of the recent proposal, including this one, the cron thing > etc. I've been wondering about a "commands" community group as well, for the various classic (and new) programs that use files, pipes, and terminals for their usual operations, but I get worried about the vast and imprecise scope, the obvious omission of library programming, and the overlap with tools, ON, and other community groups. Personally, I'd like to wait until the new Board reviews the existing community groups for activity, so we know the gaps, but otherwise, I agree that we need to recognize this kind of effort in the operating system. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Laszlo (Laca) Peter <[EMAIL PROTECTED]> [2007-02-23 11:31]: > On Fri, 2007-02-23 at 10:59 -0800, Stephen Hahn wrote: > > > > That is, why not just merge CCD, SFE, and SFW into a "freeware" > > > > consolidation that delivers appropriately to /usr, /usr/gnu, and > > > > elsewhere, and allow multiple build approaches? > > > > > > Knowing both build approaches, I simply don't see how you can > > > merge 2 vastly different build systems into a coherent system. > > > > Umm, make drives feature-level build dependencies, pkgtool builds > > individual packages, both toolsets install their packages (and test > > package dependencies) against an alternate root? > > Building against an alternate root has some serious disadvantages: > - you can't be really sure that the build doesn't pick up "stuff" >from the real root > - you need to force autotools to work in a way they weren't designed >to and it's a source of much pain and hacking There are multiple mechanisms one can use here to control the reach of your build; other (non-Solaris) build systems have managed, for instance, to use chroot(2) to control the contamination of the built objects by local state. I know JDS use of pkgbuild also allows this, so I don't think it's a stretch to consider modifications to force the SFW build to be chrooted as well. There are other approaches one could take here: contributors should build on NAT'd zones or Xen images, or whatever. The point is that a build process that is unknowably sensitive to the native install image is held to be insufficiently controlled. Others have been more eloquent to this point than I. The main point is that someone has to just pick a mechanism and articulate its costs. > > That is, SFW gives up the notion of separated proto area and package > > build phases, and pkgtool doesn't use its .spec dependency evaluation > > as part of the build. SFW and pkgtool policies on pulling versus > > keeping a static copy of upstream sources will have to be reconciled; > > there are a couple of choices here. > > > > I'm sure there are other issues, but I don't think it's unprecedented > > complexity by any means. > > Right, it can be done. I guess I just don't really see the > point. What would be the advantage of this compared to building > the 2 sets of packages separately, as if they were in a different > consolidation, even if they are delivered together? > Provided that only the pkgbuild packages depend on the SFW packages > and not the other way around, but we already have that with JDS. To me, it seems incomplete to give up on "SFW make"-built components being potentially dependent on a pkgtool-built one, when it doesn't seem to be directly ruled out. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /usr/gnu project?
* Laszlo (Laca) Peter <[EMAIL PROTECTED]> [2007-02-23 12:22]: > On Fri, 2007-02-23 at 11:51 -0800, Stephen Hahn wrote: > > > Building against an alternate root has some serious disadvantages: > > > - you can't be really sure that the build doesn't pick up "stuff" > > >from the real root > > > - you need to force autotools to work in a way they weren't designed > > >to and it's a source of much pain and hacking > > > > There are multiple mechanisms one can use here to control the reach of > > your build; other (non-Solaris) build systems have managed, for > > instance, to use chroot(2) to control the contamination of the built > > objects by local state. I know JDS use of pkgbuild also allows this, > > In fact we use chroot jails for running the JDS nightly builds, although > for a different reason -- it allows us to use the same build machine > for building different things. It also gives us confidence that we > know our dependencies. Build machines are not always, but often, shared. As I understand it, this has been a constraint on use of pkgbuild outside JDS. > > > Right, it can be done. I guess I just don't really see the > > > point. What would be the advantage of this compared to building > > > the 2 sets of packages separately, as if they were in a different > > > consolidation, even if they are delivered together? > > > Provided that only the pkgbuild packages depend on the SFW packages > > > and not the other way around, but we already have that with JDS. > > > > To me, it seems incomplete to give up on "SFW make"-built components > > being potentially dependent on a pkgtool-built one, when it doesn't > > seem to be directly ruled out. > > Okay. So what's wrong with starting to build a spec file base > separately and when SFW is ready to use them, we merge the 2 > together? > If changes need to be made to pkgbuild for this to happen, I'm > happy do so. It depends on your objectives--if you're just hoping to offer packages as an OpenSolaris effort, then a merge can be delayed indefinitely (as it seems to have been in the past); if your aim is to offer a set of binaries that get picked up by the distributions, as those of ON are, I would suggest pursuing a merge as a primary objective. Which would mean engaging with /os/projects/sfwnv/ and extending that effort's output... - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [cab-discuss] Last Day for Nominations
* Simon Phipps <[EMAIL PROTECTED]> [2007-03-05 04:15]: > None of these candidates appear to have accepted their nomination. In > addition, neither have: > > Stephen Hahn I decline the nomination, although I am very grateful for the suggestion. It seems to me that I would probably fail in attempting to juggle the responsibilities of being Sun's Technical Lead and one of the Community's Board Members. Thanks Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Community Priorities/Polling Test open
The Board has asked that the polling system being used to conduct the upcoming Board election first be tested in a meaningful way, by asking the Community's Core Contributors to prioritize potential Board initiatives for the coming year. This test poll opened at 00:00 PST March 8 and closes at 23:59 PDT March 11. See http://poll.opensolaris.org for status and links to instructions. Concerns regarding the poll content should be shared on cab-discuss; problems with the poll mechanism on website-discuss. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Board Election 2007/Ratify Constitution poll opens, 12 Mar 00:00 PDT
The polling system will shortly open for the 2007 Board election, as well as the ratification of the draft Constitution. Core Contributors from all Community Groups are eligible to participate in the poll. The poll will open at 00:00 PDT 12 March and will close at 23:59 PDT 26 March. A sample ballot may be inspected at http://mail.opensolaris.org/pipermail/cab-discuss/2007-March/001852.html The draft Constitution may be read at http://opensolaris.org/os/community/cab/governance/ Information about the candidates may be found at http://opensolaris.org/os/community/cab/OGB_Election_Status/ See http://poll.opensolaris.org for poll status and links to instructions. Eligible voters will receive reminder mail at intervals during the polling period. Again, concerns or questions regarding the poll content should be shared on cab-discuss; problems with the poll mechanism on website-discuss. - Stephen [] The "Community Priorities/Polling Test" poll has had its closing time extended by 48 hours, to 23:59 PDT 13 March. -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: User Mode Driver
* Richard Lowe <[EMAIL PROTECTED]> [2007-03-13 11:11]: > Paul Durrant wrote: > >On 3/13/07, John Plocher <[EMAIL PROTECTED]> wrote: > >>> Paul Durrant writes: > >>>>The current ON processes are just wrong for open source. > >> > >>The ON development process forces developers to look beyond > >>the current confines of their project and understand/manage > >>the impact that their development choices have on others. > >> > > That's true of most parts of the process, yes. But as Paul says below, > supplying Sun with hardware is not one of those parts (I'd be less > concerned if the entity was actual an OpenSolaris entity, but it isn't. > It's *one* distributor). > > I agree, that there are testing requirements, and there should be. But I > don't think "give Sun hardware" should be one of them, if anything it's > Sun's responsibility to acquire said hardware via whatever means it > chooses, not a requirement for the one *integrating* to gift it. > > >I don't see how giving h/w to Sun does this. I can see how that is > >required for a driver to be included in Sun's Solaris distro, but > >availability of h/w has no bearing on quality of source code. > >As I see it, ON should allow source in that passes architecture and > >peer code reviews. The distros should test, and if problems are found > >CRs should be raised. Why should one distro vendor's testing gate > >integration into the common source? Although I agree that there are problems with a "give Sun hardware" policy, I am less convinced that there shouldn't be some contributor, not employed by the device manufacturer, able to test that, with the device installed, the software actually functions according to the architectural specification. In particular, and even for devices where economics apparently preclude such distribution, I'm not sure it's in the *community's* interest to vouch for unknown device code by virtue of being integrated into the mainline. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: User Mode Driver
* David Edmondson <[EMAIL PROTECTED]> [2007-03-13 11:45]: > On Tue, Mar 13, 2007 at 11:30:20AM -0700, Stephen Hahn wrote: > > Although I agree that there are problems with a "give Sun hardware" > > policy, I am less convinced that there shouldn't be some contributor, > > not employed by the device manufacturer, able to test that, with the > > device installed, the software actually functions according to the > > architectural specification. > > How might this work for Sun developed or integrated devices or > platforms? Generally, I don't want to set up a hardware escrow/swap scheme, but instead understand how we get to some commonly held level of trust. Perhaps I am mistaken in thinking that--for ON (since other consolidations/communities could have different criteria)--Sun would achieve that level of trust rapidly. Maybe not. Specifically, it depends on whether you treat Sun as one entity--and hold to a strict interpretation of my use of "employ". Certainly there have been both reviews and testing of hardware and software components within Sun where initial versions of those components were denied integration. So there's an inside-Sun set of trust relationships that either need to be exposed, or the process needs to be restructured so that equivalent community relationships get established... - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [osol-announce] Intel Project going live
* Glynn Foster <[EMAIL PROTECTED]> [2007-03-15 15:41]: > Hi Sherry, > > Sherry Moore wrote: > > The Intel Project is now live at > > > > http://opensolaris.org/os/project/intel-platform > > > > It is a collaboration site for enhancing Solaris performance on Intel > > platforms, enabling and utilizing new features on Intel processors, > > accelerating driver availability, and other development efforts for > > making Solaris the Unix operating system of choice on Intel platforms. > > > > Discussion will take place on [EMAIL PROTECTED] > > Please see project page for details. > > I realize that you may be unable to answer these questions, but > there's a couple of things that kind of bug me a little bit - > > o Core Developers Mailing List > Subscription is restricted to people doing actual > coding or reviewing. Is this based on a social > restriction of wanting a list of good technical > content, purely legal that we can't talk about the code in > public, or otherwise? > > o onnv-intel: Anonymous push/pull is disabled. You must > either be a leader of this project (or a committer for the > onnv-intel repository) to push/pull. > > Neither of which feels very inclusive, and suggests that quite frankly, this > project might not be a good fit for *open*solaris.org. I'd love to hear some > perspective on this, and why you made the decisions you did. I think the project is trying to navigate from a "share nothing publically" position (that might be, say, conceived by a lawyer) to an "open development" position. So you are seeing an attempt to interpret legal restrictions. It might be more helpful if there was more than one repository, so that there was a clearly open repository to which code moved to (out of an anonymous repository) as it becomes ready. For that public repository, there should very clearly be a public list. I can understand a project team wanting to have a "no anonymous" repository for the early stages of development, when legal restrictions (such as patent processes, for instance) are in force, or when some component is only available in pre-production form. For these latter cases, it would be good to discuss how a non-Sun, not-Intel community member could participate (via NDA, waiver, other methods), if known. It would also be helpful to identify what technology/device/platform the open development portion is trying to cover (with links into the vast Intel website, maybe). - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Using isaexec approach
* Durga Deep Tirunagari <[EMAIL PROTECTED]> [2007-03-26 11:09]: > Hi Folks, > > We were recently developing a Cluster solution for our product. And we > are planning on using the isaexec approach. > > http://docs.sun.com/app/docs/doc/816-5138/6mba6ua5n?a=view > > Create Hardlinks to various executables and following the isaexec > approach of getexecname() and executing the appropriate binary > > isaexec does a (void) execve(mybinary, argv, envp); to execute the > actual binary. > > But how do I get the return value of the binary, I know that exec > family of functions won't return any value ?. Is there any way i can > get the return value of mybinary after it executes ?. Say if mybinary > returns 1 ( failure ) 2 ( success ) 4 ( some thing else ).. exec(2) replaces the running process image with a new image. So when mybinary calls exit(2), the exit status will be available to the parent via waitid(2). In your example, the parent would be the parent of the process which is calling isaexec(3C). - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How can we implement LaunchDaemons in MAC to Solaris10
* Srikanth <[EMAIL PROTECTED]> [2007-03-30 05:36]: > I am very new to solaris. Please see my question below. > > How can we implement LaunchDaemons in MAC to Solaris10? > > I am currently working with MAC OS X server, there we have > /System/Library/LaunchDaemons, can solaris also supports LaunchDaemons > ? Do solaris have deamons, if so where exactly they are, and how do we > implement those daemons if need to do so? Could any one provide me > details on this? If you are interested in how a daemon process would be managed on an OpenSolaris-derived system, you should investigate the Service Management Facility, via the SMF Community Group http://opensolaris.org/os/community/smf/ or its mailing list, [EMAIL PROTECTED] SMF has some goals and capabilities in common with launchd, but does not approach daemon management with identical assumptions. If you're interested in porting launchd for use by an OpenSolaris distro, then you might share your portability issues on opensolaris-code@opensolaris.org to start. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] ON C-Team or how to make the process more open
* John Plocher <[EMAIL PROTECTED]> [2007-04-03 11:09]: > James Carlson wrote: > >You've got me. I've pointed out the seeming inconsistency before on > >other threads, but John Plocher seems to think that it's not a > >problem. > > Uhmmm... > > I believe it is Stephen Hahn who is driving this "OS.o isn't a > distro, doesn't do releases and is somehow not connected to Sun's > release processes or definitions" discussion, not me. This expression is substantially broader than my position, which I held due to the immaturity of the project. My position is that we could not yet investigate the notion of a reference release of OpenSolaris, because we had insufficient participation. It may be that, with a new Board and more active Community Groups and a set of identified contributors, a proper exploration of these issues can be begun. Most of the preliminary discussions I was in suggest that it could become very complicated, if done at an "all consolidations and all software" scale. But, as we move out of bootstrap, responsibility for that priority call passes to the Board and the CGs. (Yay!) - Stephen ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Spam mails...
* Nils Nieuwejaar <[EMAIL PROTECTED]> [2007-04-15 20:45]: > Unfortunately, the volume of spam that ended up in the moderators' queue > was so unmanageable that we eventually had to start rejecting all > submissions from non-subscribers sight-unseen. That's a lousy way to have > to run a mailing list for an open source project, but we couldn't keep up. > If opensolaris.org had some halfway decent spam filters before the > moderation stage, we wouldn't have had to take that step. Since February, opensolaris.org has had halfway decent spam filters. (The problem was, prior to that, that we thought we had spam filtering, when in fact we had none.) Spam-associated moderation and administrative requests have plummeted. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Services DNS
* tarik <[EMAIL PROTECTED]> [2007-05-09 12:21]: > hello with all > under solaris 10 > I do not know for what the server service of DNS and always offline > here: > #svcs -a | grep dns > online svc:/network/dns/client:default > offline svc:/network/dns/server:default > > #svcadm enable svc:/network/dns/server > #svcadm restart dns/server > > #svcs -a | grep dns > online svc:/network/dns/client:default > offline svc:/network/dns/server:default > > help me plz Use "svcs -x" to see why network/dns/server is offline. Most likely, it's because /etc/named.conf is missing: $ svcprop -p config_data dns/server config_data/entities fmri file://localhost/etc/named.conf config_data/grouping astring require_all config_data/restart_on astring none config_data/type astring path ([EMAIL PROTECTED] is a good place to ask questions about smf(5) futures; there's a BigAdmin forum for Solaris 10 discussions at http://sun.com/bigadmin/.) - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] New Community Proposal: {Solaris} Chargeback Community
* Isaac Rozenfeld <[EMAIL PROTECTED]> [2007-05-31 14:38]: > This comes up now and then, yet I honestly believe it can benefit from > being a community effort. I guess I would expect that discussion with either the Resource Management Project http://opensolaris.org/os/project/rm/ or its main sponsoring Group, Zones, http://opensolaris.org/os/community/zones/ on their respective lists would help you refine this proposal, so that the suitability of a Community Group would be more evident. - Stephen ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
