Re: [osol-discuss] Community proposal: solaris-internals
On Thu, 2006-03-16 at 23:01, Dan Price wrote: Thumbs down to the currently proposed community. Sorry guys :( I've been following this discussion, and it seems to me that one problem we have is that the current communities are focussed around subject areas, and we don't differentiate by audience. So how do we address the needs of different audiences without creating new communities? Is it just a case of splitting the mailing lists up? -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
On Sat, Mar 18, 2006 at 06:09:38PM +, Peter Tribble wrote: I've been following this discussion, and it seems to me that one problem we have is that the current communities are focussed around subject areas, and we don't differentiate by audience. So how do we address the needs of different audiences without creating new communities? Is it just a case of splitting the mailing lists up? Yes, exactly. The focus on subject areas is intentional; that brings together the engineers designing and implementing a family of related features (in many projects) with the developers who extend or build on top of them, the users or administrators who will ultimately consume them, the documentation teams explaining how they work, and a wide variety of other people generally interested in those broadly related features/projects. I've seen several complaints here that there are no really technical mailing lists. The way to fix that, as you suggest, is simply to create new mailing lists. Of course, in most cases the really technical stuff actually belongs at the project level, where design and implementation take place. But there's no reason that communities shouldn't foster deeply technical discussion as well, especially when the subject isn't specific to a particular project. In short, the communities aren't some ethereal bodies whose existence and function have been decreed by Sun. They're *your* organisations, to serve the purposes *you*, as members, find important. If you think a particular community isn't serving a segment of its membership very well, you're welcome to work with its leaders to change that. Forming a new community is almost never the right answer. The community life cycle, and how communities choose leaders, what those leaders are expected to do, and what happens when those leaders are unresponsive to the needs and desires of their communities are important topics for discussion in the context of the Constitution. Your input would be welcome on cab-discuss. -- Keith M Wesolowski Sir, we're surrounded! Solaris Kernel Team Excellent; we can attack in any direction! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Alan Coopersmith writes: There is already a separate community for networking, so if we go that route I think this community should just be for the OS part. Then you'ld have to define OS. The official definition of the Solaris Operating System is the entire WOS, from kernel through desktop and servers, all the consolidations, so presumably you're thinking of the subset of ON that's not networking. Maybe Core OS or something? Even at that, I think it's really quite vague and likely implicitly refers to internal Sun organization more than it does anything about the code. Shouldn't STREAMS be part of any definition of OS? Why would (at a guess) procfs be part of the OS but devfs not? Other than considering historical divisions within Sun, and distinctions that likely mean little or nothing to external developers, it's not at all clear to me what the proposed OS group would cover and what it would not. (For what it's worth, I'm not happy with the existing networking group. Why wouldn't X.25, SNA, ATM, and other basic networking technologies be part of that group? Why is it just a subset of TCP/IP? But, then, if I were happy ... ;-}) -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
On Thu 03/16/06 at 17:13 PM, [EMAIL PROTECTED] wrote: Things were setup that way before projects existed and everything had to be a community. The Nevada community (which is misnamed to begin with), should become a ONNV project of an ON community which could also host your internals information. ... and proposed discussion list(s). Agreed, this proposed structure does sound a lot more sensible than the current way it's set up. Agreed. Much better. Nils ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Jim, Operating System is the entire WOS, from kernel through desktop and servers, all the consolidations, so presumably you're thinking of the subset of ON that's not networking. Maybe Core OS or something? Even at that, I think it's really quite vague and likely implicitly refers to internal Sun organization more than it does anything about the code. I agree OpenSolaris should not reflect the structure of Sun's organization . Shouldn't STREAMS be part of any definition of OS? Why would (at a guess) procfs be part of the OS but devfs not? Other than considering historical divisions within Sun, and distinctions that likely mean little or nothing to external developers, it's not at all clear to me what the proposed OS group would cover and what it would not. I agree core OS is really too nebulous. Do you have any ideas on how to break this down? A really rough strawman might look something like the following community structure in place of core OS: kernel user commands libraries but that's not perfect either. (For what it's worth, I'm not happy with the existing networking group. Why wouldn't X.25, SNA, ATM, and other basic networking technologies be part of that group? Why is it just a subset of TCP/IP? But, then, if I were happy ... ;-}) If the existence of a networking community isn't the right thing, do you believe that networking could be merged into kernel and user commands communities? Taking Linux-kernel as an example (though you can argue their model is too broad) filesystems, networking code, and even drivers are part of one community. What about file systems? Why have ZFS and UFS communities (and possibly NFS in the future) instead of one file system community with three file system projects under it? What about drivers? There's no home for them yet, and I (in my little corner of the world) expect drivers to be one of the biggest areas for contributing code as it is in other open source OSes. It sounds like there is a grumbling that the bigger picture of community structure needs to be re-thought, and that isn't what we signed up for with our proposal :), but on the other hand I certainly can see the need to rethink the whole structure. OpenSolaris has grown a lot lately, and the time might be right for a revolution. - Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Eric Lowe writes: A really rough strawman might look something like the following community structure in place of core OS: kernel user commands libraries but that's not perfect either. No, it's not. I suppose the problem is that we've really got overlapping sets here, and that no tidy breakdown is going to work. NFS is networking and it's a file system. Devfs is I/O and a core OS component. VM is (at least) file system and core OS. (And I'll refrain from ascribing memberships to STREAMS. ;-}) So, either we have to just come up with an essentially arbitrary set of groupings, and assign components to each one until the last scrawny kid gets chosen for a team, or we create lots of groupings that intentionally overlap but likely reflect much narrower interest areas. One way to deal with this sort of uncertainty is the usenet model. You create a minimal set of top level groups, and you create more focussed areas *only* when there's been an excruciating amount of traffic on one particular topic by a subset of people -- enough so that it's clear that nobody else on the general list cares, and enough so that we know the discussion isn't going to go away any time soon. In other words, create a new grouping only when pushed hard, and not when we just notice a likely-looking interest area. (For what it's worth, I'm not happy with the existing networking group. Why wouldn't X.25, SNA, ATM, and other basic networking technologies be part of that group? Why is it just a subset of TCP/IP? But, then, if I were happy ... ;-}) If the existence of a networking community isn't the right thing, do you believe that networking could be merged into kernel and user commands communities? There are certainly parts that are kernel and parts that are user commands. And there are parts that are clearly administrative in nature. There are also parts (such as the daemons) that are just other. Taking Linux-kernel as an example (though you can argue their model is too broad) filesystems, networking code, and even drivers are part of one community. That doesn't seem like an obviously bad idea to me. I see a lot of affinity among those things. What about file systems? Why have ZFS and UFS communities (and possibly NFS in the future) instead of one file system community with three file system projects under it? Indeed. What about drivers? There's no home for them yet, and I (in my little corner of the world) expect drivers to be one of the biggest areas for contributing code as it is in other open source OSes. Right. And the issues that driver writers deal with are *often* kernel issues, such as where to put common bits of functionality (we don't really want to have 27 separate MII implementations), how to deal with special functions like zero-copy (just how long can a page be pinned down?), and general locking and consistency problems. It sounds like there is a grumbling that the bigger picture of community structure needs to be re-thought, and that isn't what we signed up for with our proposal :), but on the other hand I certainly can see the need to rethink the whole structure. OpenSolaris has grown a lot lately, and the time might be right for a revolution. Just like the swamp that kernel/other represents, I suspect that there's an irreducible set of just plain old miscellany (maybe modhash goes there). But for the same reason that kernel/other is a bit of a dumping ground, it'd be good to tailor any sort of catch-all group (which is how I see core OS) so that it's a last resort rather than path of least resistance. I don't know if that represents revolution, but maybe just that core OS should be clearer on component membership. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Eric Lowe [EMAIL PROTECTED] wrote: 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. 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). If we find a way to prevent non-technical discussions as often seen on LKML, I could agree with a more tecnical list for OpenSolaris. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Eric Lowe [EMAIL PROTECTED] writes: What about file systems? Why have ZFS and UFS communities (and possibly NFS in the future) instead of one file system community with three file system projects under it? Speaking of which, it occured to me recently, when I posted a question about the interaction of zfs, automount/autofs and nfs to nfs-discuss and zfs-discuss, but got no reply whatsoever http://www.opensolaris.org/jive/thread.jspa?threadID=6717tstart=0 that a different organization of the filesystem and storage related communities might be much better than what we currently have: I can think of two models here: * Create a new filesystems community to subsume the existing zfs, ufs and nfs communities as projects. There might be a new autofs/automount community as well, and the recent proposal for a cifs community would naturally fall in as a cifs project, as has already been suggested. The problem is what to do with svm, which doesn't fall under filesystems. * Therefore, an alternative model would be to use the storage community (given that block and object based storage are getting closer recently, cf. the object storage devices work for SCSI) as an umbrella for both block-based storage (e.g. iscsi, svm projets, maybe others?) and filesystems (with the projects mentioned above). Thoughts? Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
On Fri, Rainer Orth wrote: Eric Lowe [EMAIL PROTECTED] writes: What about file systems? Why have ZFS and UFS communities (and possibly NFS in the future) instead of one file system community with three file system projects under it? Speaking of which, it occured to me recently, when I posted a question about the interaction of zfs, automount/autofs and nfs to nfs-discuss and zfs-discuss, but got no reply whatsoever http://www.opensolaris.org/jive/thread.jspa?threadID=6717tstart=0 Just FYI, the response is forthcoming; the person that was drafting something has been a little swamped. Spencer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Spencer Shepler writes: http://www.opensolaris.org/jive/thread.jspa?threadID=6717tstart=0 Just FYI, the response is forthcoming; the person that was drafting something has been a little swamped. Great, thanks. Anyway, I hope someone finds the suggested reorganization useful nonetheless :-) Rainer ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Rainer Orth wrote: Eric Lowe [EMAIL PROTECTED] writes: What about file systems? Why have ZFS and UFS communities (and possibly NFS in the future) instead of one file system community with three file system projects under it? Speaking of which, it occured to me recently, when I posted a question about the interaction of zfs, automount/autofs and nfs to nfs-discuss and zfs-discuss, but got no reply whatsoever http://www.opensolaris.org/jive/thread.jspa?threadID=6717tstart=0 that a different organization of the filesystem and storage related communities might be much better than what we currently have: I can think of two models here: * Create a new filesystems community to subsume the existing zfs, ufs and nfs communities as projects. There might be a new autofs/automount community as well, and the recent proposal for a cifs community would naturally fall in as a cifs project, as has already been suggested. The problem is what to do with svm, which doesn't fall under filesystems. * Therefore, an alternative model would be to use the storage community (given that block and object based storage are getting closer recently, cf. the object storage devices work for SCSI) as an umbrella for both block-based storage (e.g. iscsi, svm projets, maybe others?) and filesystems (with the projects mentioned above). Thoughts? After going through this thread I've had similar thoughts. Since the postings are dwindling off I think we may have more or less reached a group concensus. I'm going to go off and draft up a set of proposals to replace our original single proposal, and submit them as separate threads to facilitate further discussion. Thanks for all the great feedback everybody. I think we have a great atmosphere set here for positive change. - Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Nils Nieuwejaar wrote: 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. That sounds a lot like kernel internals - are you planning to cover user space topics as well or would kernel-internals be a better name? -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
On Thu 03/16/06 at 11:12 AM, [EMAIL PROTECTED] wrote: Nils Nieuwejaar wrote: 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. That sounds a lot like kernel internals - are you planning to cover user space topics as well or would kernel-internals be a better name? I assume most of the topics would be kernel-related, but I don't know why we would want to make that a restriction. It's not even clear that a kernel-only group would make sense given how tightly intertwined some of the elements are. How do you talk about the thread model without including libc in the discussion? On the other hand, trying to include topics about Xorg would obviously be casting too wide a net. I think what we're shooting for is really something like ON-internals, but that's probably not a term that means anything to the general OpenSolaris community. If we really wanted to be difficult, I guess we could go for SunOS-internals. Nils ___ 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
I believe this proposal needs to provide further contrasts against existing communities and projects to make aspects more clear. opensolaris-discuss is too broad an audience for internals discussions. opensolaris-code I thought was meant to cover code topics and questions, but has been overloaded to handle broader topics due to lack of a better general forum. Perhaps we could promote opensolaris-code to be the official discussion forum for internals, but I personally don't feel this is the right thing. Regardless of the discussion forum outcome, none of the existing discussion lists has a community page to host system internals documentation. We still need to fill that gap. Docs seems focused on end-user feature documentation. As for scope I'm on the fence as far as kernel-internals versus .*-internals. As long as there is something in between opensolaris-code and opensolaris-discuss which is far reaching, I'm fine with it as one of the leaders, though I prefer to err on the side of keeping it broad. 1. What is the relationship between this community and existing, demonstrably technical communities, like the networking, zones, and zfs communities? 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. 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)? Already covered above. 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. 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. 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). -- Eric Lowe Solaris Kernel Development Austin, Texas Sun Microsystems. We make the net work. x40577/+1(512)366-9080 ___ 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] Community proposal: solaris-internals
Nils Nieuwejaar 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. Things were setup that way before projects existed and everything had to be a community. The Nevada community (which is misnamed to begin with), should become a ONNV project of an ON community which could also host your internals information. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
On Thu 16 Mar 2006 at 02:19PM, Stephen Hahn wrote: * 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. I'd like to call Stephen on a technicality, but then agree with him :) There is no ON community today. There is an onnv (OS-Net Nevada) community. nv really implies a binding of that community to a particular release-- Solaris Nevada. So let me propose: - Rename and refactor the 'onnv' community into 'os-net' or some such. Remove its logical binding to the nevada release train. - Make onnv a project, logically tied to the os-net community. The C-team can run that project page. - Ponder some new convention around having -internals aliases inside of the communities (offhand, I imagine the zones, zfs, os-net and other communities might benefit). In some cases (like zones) we might want to move to a -users and -internals (or -developers) model, rather than the sort of free-for-all of -discuss. Thumbs down to the currently proposed community. Sorry guys :( Thanks, -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Things were setup that way before projects existed and everything had to be a community. The Nevada community (which is misnamed to begin with), should become a ONNV project of an ON community which could also host your internals information. ... and proposed discussion list(s). Agreed, this proposed structure does sound a lot more sensible than the current way it's set up. - Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Eric Lowe wrote: So let me propose: - Rename and refactor the 'onnv' community into 'os-net' or some such. Remove its logical binding to the nevada release train. There is already a separate community for networking, so if we go that route I think this community should just be for the OS part. Then you'ld have to define OS. The official definition of the Solaris Operating System is the entire WOS, from kernel through desktop and servers, all the consolidations, so presumably you're thinking of the subset of ON that's not networking. Maybe Core OS or something? -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Then you'ld have to define OS. The official definition of the Solaris Operating System is the entire WOS, from kernel through desktop and servers, all the consolidations, so presumably you're thinking of the subset of ON that's not networking. Maybe Core OS or something? Yes, core OS - kernel, utilities, and libraries. X, freeware, etc. I would imagine would eventually have their own communities on OpenSolaris, or communities outside of Sun already? - Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community proposal: solaris-internals
Jumping in...from the docs community perspective, it would be great to have a repository for technical design documentation as proposed here. Documentation (design, arc, admin, user, dev, etc.) cuts across the whole of the OpenSolaris project and should be a top-level item when you arrive at opensolaris.org. Otherwise, folks have to drill into each community and project to find technical info (boring) and people can't get a big-picture view of all the documents available to them or see where they might fill a gap, learn something new, or get help independently (confusing). Bug 6370879 was filed on this, but hasn't been implemented yet. -Michelle X-Original-To: opensolaris-discuss@opensolaris.org Delivered-To: opensolaris-discuss@opensolaris.org Date: Thu, 16 Mar 2006 17:13:55 -0600 From: Eric Lowe [EMAIL PROTECTED] Subject: Re: [osol-discuss] Community proposal: solaris-internals To: Alan Coopersmith [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060113) Cc: Nils Nieuwejaar [EMAIL PROTECTED], opensolaris-discuss@opensolaris.org, Stephen Hahn [EMAIL PROTECTED] X-BeenThere: opensolaris-discuss@opensolaris.org X-Mailman-Version: 2.1.4 List-Id: General OpenSolaris Discussion List opensolaris-discuss.opensolaris.org List-Unsubscribe: http://mail.opensolaris.org/mailman/listinfo/opensolaris-discuss, mailto:[EMAIL PROTECTED] e List-Archive: http://mail.opensolaris.org/pipermail/opensolaris-discuss List-Post: mailto:opensolaris-discuss@opensolaris.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://mail.opensolaris.org/mailman/listinfo/opensolaris-discuss, mailto:[EMAIL PROTECTED] Things were setup that way before projects existed and everything had to be a community. The Nevada community (which is misnamed to begin with), should become a ONNV project of an ON community which could also host your internals information. ... and proposed discussion list(s). Agreed, this proposed structure does sound a lot more sensible than the current way it's set up. - Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
