Hello zfs-discuss,
Simple test ''ptime find /zfs/filesystem >/dev/null'' with
2GB RAM.
After second, third, etc. time still it reads a lot from disks while
find is running (atime is off).
on x64 (Opteron) it doesn''t.
I guess it''s due to 512MB heap limit in kernel for its cache.
::memstat shows 469MB for kernel and 1524MB on freelist.
Is there anything could be done? I guess not but perhaps....
ps. of course there''re a lot of files like ~150K.
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
Yup, your probably running up against the limitations of 32-bit kernel addressability. We are currently very conservative in this environment, and so tend to end up with a small cache as a result. It may be possible to tweak things to get larger cache sizes, but you run the risk of starving out other processes trying to get memory. -Mark Robert Milkowski wrote:> Hello zfs-discuss, > > Simple test ''ptime find /zfs/filesystem >/dev/null'' with 2GB RAM. > After second, third, etc. time still it reads a lot from disks while > find is running (atime is off). > > on x64 (Opteron) it doesn''t. > > I guess it''s due to 512MB heap limit in kernel for its cache. > ::memstat shows 469MB for kernel and 1524MB on freelist. > > > Is there anything could be done? I guess not but perhaps.... > > > > ps. of course there''re a lot of files like ~150K.
What if your 32bit system is just a NAS -- ZFS and NFS, nothing else? I think it would still be ideal to allow tweaking of things at runtime to make 32-bit systems more ideal. On 6/21/06, Mark Maybee <Mark.Maybee at sun.com> wrote:> Yup, your probably running up against the limitations of 32-bit kernel > addressability. We are currently very conservative in this environment, > and so tend to end up with a small cache as a result. It may be > possible to tweak things to get larger cache sizes, but you run the risk > of starving out other processes trying to get memory. > > -Mark > > Robert Milkowski wrote: > > Hello zfs-discuss, > > > > Simple test ''ptime find /zfs/filesystem >/dev/null'' with 2GB RAM. > > After second, third, etc. time still it reads a lot from disks while > > find is running (atime is off). > > > > on x64 (Opteron) it doesn''t. > > > > I guess it''s due to 512MB heap limit in kernel for its cache. > > ::memstat shows 469MB for kernel and 1524MB on freelist. > > > > > > Is there anything could be done? I guess not but perhaps.... > > > > > > > > ps. of course there''re a lot of files like ~150K. > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
On Thu, 22 Jun 2006, Joe Little wrote: Please don''t top post.> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else? > I think it would still be ideal to allow tweaking of things at runtime > to make 32-bit systems more ideal.I respectfully disagree. Even on x86, 64-bits are common, and the price difference between 64-bit and 32-bit capable systems is small. So apart from keeping old stuff working, I can think of little or no justifcation to not go with 64-bit systems these days, even for a small S10 plus ZFS NAS appliance. That way you leave behind all the pain 32-bits gives you. -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich
Rich Teer wrote:> On Thu, 22 Jun 2006, Joe Little wrote: > > Please don''t top post. > >> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else? >> I think it would still be ideal to allow tweaking of things at runtime >> to make 32-bit systems more ideal. > > I respectfully disagree. Even on x86, 64-bits are common, and the > price difference between 64-bit and 32-bit capable systems is small. > So apart from keeping old stuff working, I can think of little or no > justifcation to not go with 64-bit systems these days, even for a small > S10 plus ZFS NAS appliance. That way you leave behind all the pain > 32-bits gives you.Are VIA processor chips 64bit capable yet ? -- Darren J Moffat
>Are VIA processor chips 64bit capable yet ?No, I don''t think so. And Geode? Casper
On 6/22/06, Darren J Moffat <Darren.Moffat at sun.com> wrote:> Rich Teer wrote: > > On Thu, 22 Jun 2006, Joe Little wrote: > > > > Please don''t top post. > > > >> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else? > >> I think it would still be ideal to allow tweaking of things at runtime > >> to make 32-bit systems more ideal. > > > > I respectfully disagree. Even on x86, 64-bits are common, and the > > price difference between 64-bit and 32-bit capable systems is small. > > So apart from keeping old stuff working, I can think of little or no > > justifcation to not go with 64-bit systems these days, even for a small > > S10 plus ZFS NAS appliance. That way you leave behind all the pain > > 32-bits gives you. > > Are VIA processor chips 64bit capable yet ? > > -- > Darren J Moffat >Well, current Xeon-LVs are 32 bit only, but besides the point, I''m in education, where our storage boxes are purchased using grant money that must be utilized for x number of years. The answer from Rich Teer indicates that we should dump old infrastructure and buy new, or if you are in our industry (I represent Stanford University Electrical Engineering), take your money/infrastructure elsewhere as only new customers need apply :( A lot of organizations have a lot of 32 bit infrastructure with multiple RAID cards, drives, etc that they''d love to migrate over to ZFS. I''m using it now for creating large pools of 2nd tier storage. And yes, that will mostly be pre-existing hardware.
Joe Little wrote:> On 6/22/06, Darren J Moffat <Darren.Moffat at sun.com> wrote: >> Rich Teer wrote: >> > On Thu, 22 Jun 2006, Joe Little wrote: >> > >> > Please don''t top post. >> > >> >> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else? >> >> I think it would still be ideal to allow tweaking of things at runtime >> >> to make 32-bit systems more ideal.UTSL :-) But I think there is an opportunity for documentation here which is being missed. Remember, 32-bit systems can have lots of memory, >> 4 GBytes. It would seem a shame to not make this a percentage of memory rather than an arbitrary fixed amount. -- richard
On Thu, 22 Jun 2006, Joe Little wrote:> On 6/22/06, Darren J Moffat <Darren.Moffat at sun.com> wrote: > > Rich Teer wrote: > > > On Thu, 22 Jun 2006, Joe Little wrote: > > > > > > Please don''t top post. > > > > > >> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else? > > >> I think it would still be ideal to allow tweaking of things at runtime > > >> to make 32-bit systems more ideal. > > > > > > I respectfully disagree. Even on x86, 64-bits are common, and the > > > price difference between 64-bit and 32-bit capable systems is small. > > > So apart from keeping old stuff working, I can think of little or no > > > justifcation to not go with 64-bit systems these days, even for a small > > > S10 plus ZFS NAS appliance. That way you leave behind all the pain > > > 32-bits gives you. > > > > Are VIA processor chips 64bit capable yet ? > > > > -- > > Darren J Moffat > > > > Well, current Xeon-LVs are 32 bit only, but besides the point, I''m in > education, where our storage boxes are purchased using grant money > that must be utilized for x number of years. The answer from Rich Teer > indicates that we should dump old infrastructure and buy new, or if > you are in our industry (I represent Stanford University Electrical > Engineering), take your money/infrastructure elsewhere as only new > customers need apply :( A lot of organizations have a lot of 32 bitWhile it may appear that he was being dismissive of your issues, I''m sure that was not his intention (knowing the personality involved). And your issue is very real. Juergen Keil <jk at tools.de> (amoung others) has already (expertly) identified the ZFS issues that occur from kernal memory starvation on a 32-bit platform. And between ZFS and DTrace - the Virtual Memory management code is being (overly) "stressed" - to put it mildly. All you need is a 32-bit only (Open)Solaris driver to ruin your ZFS parade. Can anyone say Qlogic 2x00 ! :( I can!> infrastructure with multiple RAID cards, drives, etc that they''d love > to migrate over to ZFS. I''m using it now for creating large pools of > 2nd tier storage. And yes, that will mostly be pre-existing hardware.A possible solution would be to acquire one, fast 64-bit box and set it up to be a NAS server running ZFS on the back-end. But quite honestly, with hardware costs continuing to decrease, I''m not sure, that if I were Sun Management, that I''d be priortizing work on older 32-bit only platforms and drivers. ZFS is awesome technology - but, sadly, only those who can pay the "admission price" will be able to reap the full benefits of it. Life and times in the Big City. Regards, Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 OpenSolaris Governing Board (OGB) Member - Feb 2006
AMD Geodes are 32-bit only. I haven''t heard any mention that they will _ever_ be 64-bit. But, honestly, this and the Via chip aren''t really ever going to be targets for Solaris. That is, they simply aren''t (any substantial) part of the audience we''re trying to reach with Solaris x86. Also, relatively few 32-bit x86 systems can take > 4GB. While many of the late-model P4 (and all Xeons since the P3 Xeon) chips have the capability, most of them were married to chipsets which can''t take more than 4GB. On the AMD side, I''m pretty sure only the Athlon MP-series was enabled for PAE, and only a tiny amount of them were sold. So, basically, the problem boils down to those with Xeons, a few single-socket P4s, and some of this-year''s Pentium Ds. Granted, this makes up most of the x86 server market. So, yes, it _would_ be nice to be able to dump a tuning parameter into /etc/system to fix the cache starvation (and other related <4GB RAM) problems. However, I have to say that working with PAE is messy, and, honestly, 64-bit enabled 1U/3U servers are dirt cheap now. So, while I empathize with the market that has severe purchasing constraints, I think it''s entirely reasonable to be up front about needing a 64-bit processor for ZFS, _if_ we''ve explored expanding the 32-bit environment, and discovered it was too expensive (in resources required) to fix. Dell (arrggh! Not THEM!) sells PowerEdge servers with plenty of PCI slots and RAM, and 64-bit CPUs for around $1000 now. Hell, WE sell dual-core x2100s for under $2k. I''m sure one can pick up a whitebox single-core Opteron for around $1k. That''s not unreasonable to ask to get the latest technology. -Erik
> AMD Geodes are 32-bit only. I haven''t heard any mention that they will > _ever_ be 64-bit. But, honestly, this and the Via chip aren''t really > ever going to be targets for Solaris. That is, they simply aren''t (any > substantial) part of the audience we''re trying to reach with Solaris x86.Didn''t know our audience was made up of CPUs :) I like to think (when in a good mood) that we are trying to reach creative people who can take OpenSolaris where Sun haven''t imagined or been able to. -Artem.
Artem Kachitchkine wrote:> >> AMD Geodes are 32-bit only. I haven''t heard any mention that they >> will _ever_ be 64-bit. But, honestly, this and the Via chip aren''t >> really ever going to be targets for Solaris. That is, they simply >> aren''t (any substantial) part of the audience we''re trying to reach >> with Solaris x86. > > Didn''t know our audience was made up of CPUs :) I like to think (when > in a good mood) that we are trying to reach creative people who can > take OpenSolaris where Sun haven''t imagined or been able to. > > -Artem. >Then let those folks fix the problem. The issue here is what amount of effort _Sun_ can put into fixing 32-bit Solaris so as to enable ZFS to comfortably run on it. We (Sun) aren''t preventing anyone from moving OpenSolaris in a direction that Sun hasn''t contemplated (or decided). But, we can''t accommodate everyone''s desires, so we pick what is important to us. And, the 32-bit only embedded market (which is where the Geode and Via chips are targetted) isn''t on our immediate target list. That''s the Joy of OpenSource - if you want it, fix it! But don''t expect anyone else to ever do it. ;-) -Erik
Erik Trimble wrote:> Dell (arrggh! Not THEM!) sells PowerEdge servers with plenty of PCI > slots and RAM, and 64-bit CPUs for around $1000 now. Hell, WE sell > dual-core x2100s for under $2k. I''m sure one can pick up a whitebox > single-core Opteron for around $1k. That''s not unreasonable to ask to > get the latest technology.Don''t sell us short! A Sun X2100 (single core Opteron) starts at $745 list. Add your disk and memory and should come out around $1k... no need for a white box. If you need a physically bigger box with more slots, the Sun Ultra-20 with disk lists at $895. Or for DIY, an Athlon64 3200+ with mobo starts at $99. For small form factors, MicroATX mobo + Sempron64 is around $142.99. For a laptop, $599 will get you a Turion64-based system. Dense memory will raise the price a bit, but clearly these are inexpensive enough that hardware cost shouldn''t be much of a barrier. -- richard
I guess the only hope is to find pin-compatible Xeons that are 64bit to replace what is a large chassis with 24 slots of disks that has specific motherboard form-factor, etc. We have 6 of these things from a government grant that must be used for the stated purpose. So, yes, we can buy product, but we simply can''t get rid of the old equipment designed for this purpose. Again, government auditors for the research will say "pick the solution for the hardware has donated/purchased with grant funds" -- Welcome to the world of research. If Sun wants to _give_ us lots of hardware to make ZFS shine, great. But as is usually the case, I got to make do with what I have. For the vast majority of the storage, I''m running them as iscsi targets with a single sun ultra20 as the frontend, but as from other messages in the list, the iscsi route along with NFS has its own pitfalls, 32bit or 64bit :) On 6/22/06, Erik Trimble <Erik.Trimble at sun.com> wrote:> AMD Geodes are 32-bit only. I haven''t heard any mention that they will > _ever_ be 64-bit. But, honestly, this and the Via chip aren''t really > ever going to be targets for Solaris. That is, they simply aren''t (any > substantial) part of the audience we''re trying to reach with Solaris x86. > > Also, relatively few 32-bit x86 systems can take > 4GB. While many of > the late-model P4 (and all Xeons since the P3 Xeon) chips have the > capability, most of them were married to chipsets which can''t take more > than 4GB. On the AMD side, I''m pretty sure only the Athlon MP-series was > enabled for PAE, and only a tiny amount of them were sold. > > So, basically, the problem boils down to those with Xeons, a few > single-socket P4s, and some of this-year''s Pentium Ds. Granted, this > makes up most of the x86 server market. So, yes, it _would_ be nice to > be able to dump a tuning parameter into /etc/system to fix the cache > starvation (and other related <4GB RAM) problems. However, I have to > say that working with PAE is messy, and, honestly, 64-bit enabled 1U/3U > servers are dirt cheap now. So, while I empathize with the market that > has severe purchasing constraints, I think it''s entirely reasonable to > be up front about needing a 64-bit processor for ZFS, _if_ we''ve > explored expanding the 32-bit environment, and discovered it was too > expensive (in resources required) to fix. > > Dell (arrggh! Not THEM!) sells PowerEdge servers with plenty of PCI > slots and RAM, and 64-bit CPUs for around $1000 now. Hell, WE sell > dual-core x2100s for under $2k. I''m sure one can pick up a whitebox > single-core Opteron for around $1k. That''s not unreasonable to ask to > get the latest technology. > > -Erik > >
>AMD Geodes are 32-bit only. I haven''t heard any mention that they will >_ever_ be 64-bit. But, honestly, this and the Via chip aren''t really >ever going to be targets for Solaris. That is, they simply aren''t (any >substantial) part of the audience we''re trying to reach with Solaris x86.I''m not sure that we want to limit the Solaris target in that way; we want laptops, small embedded systems as well as big iron. The more systems Solaris runs on the bigger the eco system. If it means no high thruput ZFS, then that is fine with me and certainly I would not prioritize this. And we don''t want "1U" systems; we want mini-ITX, nearly silent systems which can fit in cars or which can be easily hidden away. The price is not the objection; it''s the form factor. Casper
Erik Trimble wrote:> AMD Geodes are 32-bit only. I haven''t heard any mention that they will > _ever_ be 64-bit. But, honestly, this and the Via chip aren''t really > ever going to be targets for Solaris. That is, they simply aren''t (any > substantial) part of the audience we''re trying to reach with Solaris x86.I really beg to differ on the VIA chip. The VIA chip is VERY interesting to some of us due to its onboard AES and RSA capability. The onboard AES makes it very interesting to me for ZFS crypto. Think about a secure consumer targeted storage applicance that does encryption and uses ZFS for the file storage. There is a whole community building up else where on OpenSolaris.org just for applicances and NAS is one of the areas of discussion. -- Darren J Moffat
Erik Trimble wrote:> Artem Kachitchkine wrote: >> >>> AMD Geodes are 32-bit only. I haven''t heard any mention that they >>> will _ever_ be 64-bit. But, honestly, this and the Via chip aren''t >>> really ever going to be targets for Solaris. That is, they simply >>> aren''t (any substantial) part of the audience we''re trying to reach >>> with Solaris x86. >> >> Didn''t know our audience was made up of CPUs :) I like to think (when >> in a good mood) that we are trying to reach creative people who can >> take OpenSolaris where Sun haven''t imagined or been able to. >> >> -Artem. >> > Then let those folks fix the problem. The issue here is what amount of > effort _Sun_ can put into fixing 32-bit Solaris so as to enable ZFS to > comfortably run on it.This is an @opensolaris.org alias it is about working together as a community and identifying problems and discovering solutions. I don''t think it is at all appropriate to bring up Sun business choices here. Where that is appropriate is when Sun employees need to justify to their manager what they are working on. -- Darren J Moffat
Darren J Moffat wrote:> This is an @opensolaris.org alias it is about working together as a > community and identifying problems and discovering solutions. I don''t > think it is at all appropriate to bring up Sun business choices here. > Where that is appropriate is when Sun employees need to justify to > their manager what they are working on. >Darren brings up a good point here, and I thank him for making me remember that this isn''t just a Sun-only developer list. However, this does bring to light a current problem: who is working on what, and how do the various "sponsoring" entities prioritize work? I''ve run into this problem on a couple of large Open Source projects, and we do need to make things a bit more transparent. We have the same problem over here in the Java group - how do we coordinate bugfixing and feature additions within a large community of developers and users, where developers may come from a variety of sources, and users may also be interested in providing not just feedback/RFEs, but actual sponsorship for developer time. Obviously, a developer is going to be most interested in producing work that their sponsor thinks is important (and, naturally, it is very possible for a developer to be his or her own sponsor). For a developer who doesn''t have specific work directed by the sponsor, there needs to be some way for the community to prioritize work for that developer. That is, we as the community need to be able to let the developers know what is important to us, in an organized way. Personally, I''d like to have the ZFS community have an open bug and RFE system that looks like the one for Java (check out: http://bugs.sun.com/bugdatabase/index.jsp), or something that provides similar features. We (the users) would have a much easier way to hunt down things going on with developers'' work, and developers would have a much easier time determining what is considered widely important to the user community. I''ve previously bitched about a lack of view of feature schedules for ZFS. This would solve that problem, also. How about it folks - would it be a good idea for me to explore what it takes to get such a bug/RFE setup implemented for the ZFS community on OpenSolaris.org? -Erik
> How about it folks - would it be a good idea for me to explore what it > takes to get such a bug/RFE setup implemented for the ZFS community on > OpenSolaris.org?what''s wrong with http://bugs.opensolaris.org/bugdatabase/index.jsp for finding bugs? i think we''ve been really good about taking reported problems and filing bugs - if others disagree, feel free to speak up. I think what you''re asking for should be solved at the opensolaris community level (if its not already there) - not specifically for ZFS. eric
>>>>> "EK" == eric kustarz <Eric.Kustarz at sun.com> writes:EK> what''s wrong with http://bugs.opensolaris.org/bugdatabase/index.jsp EK> for finding bugs? Unless they''ve fixed it recently, the "keywords" search doesn''t actually check against the Bugster keywords field. And the information presented is pretty limited. I think there are other issues, but these are the ones that annoy me the most. We (the OpenSolaris core team) have been working with the people who own the b.o.o code to fix some of the most glaring issues in the short-term. We''ve also been working with the Bugster folks to come up with a long-term plan that puts the external community on more-or-less equal footing with Sun employees. (The difference would be that you have to be a Sun employee to see confidential information, like customer account names.) EK> I think what you''re asking for should be solved at the opensolaris EK> community level (if its not already there) - not specifically for EK> ZFS. Yes, please. If we can''t work within the b.o.o framework (which is not an obvious conclusion to me), then at least let''s implement something for the entire site. Having community-specific bug functionality is just going to mean duplicated work and an uneven user experience. mike
[resend with corrected cc list -mdk]>>>>> "EK" == eric kustarz <Eric.Kustarz at sun.com> writes:EK> what''s wrong with http://bugs.opensolaris.org/bugdatabase/index.jsp EK> for finding bugs? Unless they''ve fixed it recently, the "keywords" search doesn''t actually check against the Bugster keywords field. And the information presented is pretty limited. I think there are other issues, but these are the ones that annoy me the most. We (the OpenSolaris core team) have been working with the people who own the b.o.o code to fix some of the most glaring issues in the short-term. We''ve also been working with the Bugster folks to come up with a long-term plan that puts the external community on more-or-less equal footing with Sun employees. (The difference would be that you have to be a Sun employee to see confidential information, like customer account names.) EK> I think what you''re asking for should be solved at the opensolaris EK> community level (if its not already there) - not specifically for EK> ZFS. Yes, please. If we can''t work within the b.o.o framework (which is not an obvious conclusion to me), then at least let''s implement something for the entire site. Having community-specific bug functionality is just going to mean duplicated work and an uneven user experience. mike
On Fri, 2006-06-23 at 10:09 -0700, eric kustarz wrote:> > How about it folks - would it be a good idea for me to explore what it > > takes to get such a bug/RFE setup implemented for the ZFS community on > > OpenSolaris.org? > > > what''s wrong with http://bugs.opensolaris.org/bugdatabase/index.jsp for > finding bugs? > > i think we''ve been really good about taking reported problems and filing > bugs - if others disagree, feel free to speak up. > > I think what you''re asking for should be solved at the opensolaris > community level (if its not already there) - not specifically for ZFS. > > eric >It is a good start (yes, I know it''s an interface to Bugster, just as the Java one I pointed out is too - in fact, it''s probably the same code). And, I''m certainly not complaining about how well people have been taking to and addressing bugs. However, there are some significant shortcomings with the interface that need to be fixed. And, yes, this is true w/r/t the OpenSolaris community as a whole. Basically, the problem is that the OpenSolaris portal itself is extremely primitive, and really needs a big overhaul to make the information we have easily accessible in a coherent manner. And, in addition, the bug portal isn''t really useful for helping manage external (to Sun) contributors work. And it doesn''t given any real insight into who''s working on what, and what schedules might be. -- Erik Trimble Java System Support Mailstop: usca14-102 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800)
On Jun 23, 2006, at 1:09 PM, eric kustarz wrote:> >> How about it folks - would it be a good idea for me to explore >> what it takes to get such a bug/RFE setup implemented for the ZFS >> community on OpenSolaris.org? > > > what''s wrong with http://bugs.opensolaris.org/bugdatabase/index.jsp > for finding bugs?There''s a LOT of things wrong with how b.s.o is presented. For us non-Sun people, b.s.o is a one-way ticket, and only when we''re lucky. First, yes, we can search on bug keywords and categories. Great. Used to need a Sunsolve acct for this. But once we do that, we can only hope that the bugs we want to read about in detail aren''t comprised solely of "See Notes" and that''s it. It''s like seeing "To be continued..." right before the climax of a movie. Useless and frustrating. Second, while there is a way for Joe Random to submit a bug, there is zero way for Joe Random to interact with a bug. No voting to bump or drop a priority, no easy way to find hot topic bugs, no way to add one''s own notes to the issue. I guess the desperate just have to clog the system with new bugs and have them marked as dups or badger someone with a sun.com email address to do it for us. Third, much of end-to-end bug servicing from a non-Sun perspective is still an uphill battle, from acronyms and terms used to policies and coordination of work, e.g. "Is someone in Sun or elsewhere already working on this particular bug I''m interested in?" and questions which would stem from that basic one. In summary, the bug/RFE process is still a mystery after 1 year, and who knows if it''ll stay the ginormous tease that it currently is. Really, it''s still no better than if one had a Sunsolve account in years'' past. /dale
* Erik Trimble <Erik.Trimble at sun.com> [2006-06-23 11:15]:> It is a good start (yes, I know it''s an interface to Bugster, just as > the Java one I pointed out is too - in fact, it''s probably the same > code). And, I''m certainly not complaining about how well people have > been taking to and addressing bugs. > > However, there are some significant shortcomings with the interface that > need to be fixed. And, yes, this is true w/r/t the OpenSolaris community > as a whole. Basically, the problem is that the OpenSolaris portal > itself is extremely primitive, and really needs a big overhaul to make > the information we have easily accessible in a coherent manner.Please come to either of website-discuss or tools-discuss and share your thoughts for improvement (or at least de-primitivization).> And, in addition, the bug portal isn''t really useful for helping manage > external (to Sun) contributors work. And it doesn''t given any real > insight into who''s working on what, and what schedules might be.I am not sure whether you are commenting on the lack of publication from the internal database (which may have this information), or the lack of this information more generally. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
On Fri, Jun 23, 2006 at 02:20:54PM -0400, Dale Ghent wrote:> Second, while there is a way for Joe Random to submit a bug, there is > zero way for Joe Random to interact with a bug. No voting to bump or > drop a priority, no easy way to find hot topic bugs, no way to add > one''s own notes to the issue. I guess the desperate just have to clog > the system with new bugs and have them marked as dups or badger > someone with a sun.com email address to do it for us.Aside: we track bug severity and priority separately. The former is for customers to decide, and each customer may assert different severities for the same bug, while the latter is for engineers and management to decide. As for the "See comments" problem, us engineers have been told to stop doing that, so that you should see very few _new_ CRs of that sort.> In summary, the bug/RFE process is still a mystery after 1 year, and > who knows if it''ll stay the ginormous tease that it currently is.I hope not. Nico --
* Dale Ghent <daleg at elemental.org> [2006-06-23 11:28]:> On Jun 23, 2006, at 1:09 PM, eric kustarz wrote: > Third, much of end-to-end bug servicing from a non-Sun perspective is > still an uphill battle, from acronyms and terms used to policies and > coordination of work, e.g. "Is someone in Sun or elsewhere already > working on this particular bug I''m interested in?" and questions > which would stem from that basic one. > > In summary, the bug/RFE process is still a mystery after 1 year, and > who knows if it''ll stay the ginormous tease that it currently is. > Really, it''s still no better than if one had a Sunsolve account in > years'' past.Because of those acronyms and terms (and the processes that generate them), you can probably imagine the issues with cleaning and publishing a database that formerly contained private and confidential information only. We are still debating whether a cleanup process can ever complete successfully, or whether we need to make a more drastic adjustment. However, we can attempt to clear up any mysteriousness about the processes as we understand them on the open development side. If a document to this effect would help, then we can make drafting one a priority. (If, instead, the goal is to document how Sun''s service organization handles service requests, then that''s not really appropriate for OpenSolaris to tackle.) (But this topic also is for tools-discuss.) - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
Please refer all followups to this thread over to the website-discuss at opensolaris.org list. On Fri, 2006-06-23 at 11:27 -0700, Stephen Hahn wrote:> * Erik Trimble <Erik.Trimble at sun.com> [2006-06-23 11:15]: > > It is a good start (yes, I know it''s an interface to Bugster, just as > > the Java one I pointed out is too - in fact, it''s probably the same > > code). And, I''m certainly not complaining about how well people have > > been taking to and addressing bugs. > > > > However, there are some significant shortcomings with the interface that > > need to be fixed. And, yes, this is true w/r/t the OpenSolaris community > > as a whole. Basically, the problem is that the OpenSolaris portal > > itself is extremely primitive, and really needs a big overhaul to make > > the information we have easily accessible in a coherent manner. > > Please come to either of website-discuss or tools-discuss and share > your thoughts for improvement (or at least de-primitivization). > > > And, in addition, the bug portal isn''t really useful for helping manage > > external (to Sun) contributors work. And it doesn''t given any real > > insight into who''s working on what, and what schedules might be. > > I am not sure whether you are commenting on the lack of publication > from the internal database (which may have this information), or the > lack of this information more generally. > > - StephenAs several others have pointed out, the current Bug/RFE interface is seriously broken for non-Sun users, and is missing quite a bit of functionality (both in the interface and in the data being stored) even for internal Sun folks. Off the top of my head: 1. The categories for bug submission and searching really need to be rethought. At the minimum, the search function should probably be more in line with the various communities on OS.org. That is, you probably should have main categories which line up with each of the O.S. communities, with subcategories being more specific. 2. Viewing bugs is a mess - access varies widely across external and internal users, bugs aren''t consistently found/displayed, etc. 3. There is no development schedule information stored/available. e.g. when a particular Bug/RFE is expected to be fixed/included. 4. Who is working on a bug/RFE isn''t available. 5. External users are effectively shut out of the bug/RFE database. It should be possible for a (properly authorized) external user to both update a bug status, and/or take ownership of the bug/RFE. 6. A better community-centric bug/RFE prioritization method needs to be developed. 7. Bug/RFE bounties need to be considered, along with a method of funding and payout for them 8. The UI for the whole Bug/RFE setup needs a drastic overhaul to make it simpler to view multiple/related bugs. -- Erik Trimble Java System Support Mailstop: usca14-102 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800)
> Erik Trimble wrote: > This is an @opensolaris.org alias it is about working > together as a > community and identifying problems and discovering > solutions. I don''t > think it is at all appropriate to bring up Sun > business choices here. > Where that is appropriate is when Sun employees need > to justify to their > manager what they are working on.Actually, it was nice to see someone actually say why they knew or believed SUN to not be pursuing this particular option. It was better than no response at all, and it was certainly better than "we''re not pursuing that" without an explanation. Personally, his explanation that it wasn''t in SUN''s target market, but nothing would stop the community from pursuing it seemed perfectly reasonable to me. As long as SUN continues to be willing to accept community contributions, even for those areas they aren''t targeting, to be integrated, I think it''s fine. -Shawn This message posted from opensolaris.org
Hello Erik,
Friday, June 23, 2006, 2:35:30 AM, you wrote:
ET> So, basically, the problem boils down to those with Xeons, a few
ET> single-socket P4s, and some of this-year''s Pentium Ds. Granted,
this
ET> makes up most of the x86 server market. So, yes, it _would_ be nice to
ET> be able to dump a tuning parameter into /etc/system to fix the cache
ET> starvation (and other related <4GB RAM) problems. However, I have to
ET> say that working with PAE is messy, and, honestly, 64-bit enabled 1U/3U
ET> servers are dirt cheap now. So, while I empathize with the market that
ET> has severe purchasing constraints, I think it''s entirely
reasonable to
ET> be up front about needing a 64-bit processor for ZFS, _if_ we''ve
ET> explored expanding the 32-bit environment, and discovered it was too
ET> expensive (in resources required) to fix.
It''s reasonable.
However in many datacenters with x86 gear there''re a lot of old 32bit
Xeon boxes and in many cases ZFS will be useless (too slow). Most of
these boxes have 2GB/4GB of ram and ZFS will use less than 512MB of
its caches (metadata/data).
I know I can switch to x64 server - but it doesn''t make sense for that
application - and we won''t just throw away all old hardware.
Right now we''re testing UFS (it''s running Linux in a
production and we
want to switch to Solaris).
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
Richard Lowe
2007-Jan-10 16:24 UTC
[website-discuss] Re: [zfs-discuss] Priorities (moving forums...)
Erik Trimble wrote:> Please refer all followups to this thread over to the > website-discuss@opensolaris.org list.>> > On Fri, 2006-06-23 at 11:27 -0700, Stephen Hahn wrote: >> * Erik Trimble <Erik.Trimble@sun.com> [2006-06-23 11:15]: >>> It is a good start (yes, I know it''s an interface to Bugster, just as >>> the Java one I pointed out is too - in fact, it''s probably the same >>> code). And, I''m certainly not complaining about how well people have >>> been taking to and addressing bugs. >>> >>> However, there are some significant shortcomings with the interface that >>> need to be fixed. And, yes, this is true w/r/t the OpenSolaris community >>> as a whole. Basically, the problem is that the OpenSolaris portal >>> itself is extremely primitive, and really needs a big overhaul to make >>> the information we have easily accessible in a coherent manner. >> Please come to either of website-discuss or tools-discuss and share >> your thoughts for improvement (or at least de-primitivization). >> >>> And, in addition, the bug portal isn''t really useful for helping manage >>> external (to Sun) contributors work. And it doesn''t given any real >>> insight into who''s working on what, and what schedules might be. >> I am not sure whether you are commenting on the lack of publication >> from the internal database (which may have this information), or the >> lack of this information more generally. >> >> - Stephen > > > As several others have pointed out, the current Bug/RFE interface is > seriously broken for non-Sun users, and is missing quite a bit of > functionality (both in the interface and in the data being stored) even > for internal Sun folks. > > > Off the top of my head: > > 1. The categories for bug submission and searching really need to be > rethought. At the minimum, the search function should probably be more > in line with the various communities on OS.org. That is, you probably > should have main categories which line up with each of the O.S. > communities, with subcategories being more specific.cat/subcat when searching should be the *real* category and subcategory, What you suggested would be a nice extra, but is no replacement for allowing this to be based on what is, after all, the real information.> > 2. Viewing bugs is a mess - access varies widely across external and > internal users, bugs aren''t consistently found/displayed, etc.To expand. More fields need to be visible. We''re all aware of why this isn''t done, and the problems involved, I believe. But a solution needs to be found to at least display such fields as Evaluation, which fairly often (I believe) contain useful information. Comments, and the ability to add same would also be good, but perhaps even more problematic. As mentioned in the last discussion on this topic, ceasing to mangle Status would be a fine start, even. (and teaching the email mangler to stop mangling device paths and similar would deal with something that, while perhaps trivial, annoys the hell out of me) :)> 3. There is no development schedule information stored/available. e.g. > when a particular Bug/RFE is expected to be fixed/included.>> 4. Who is working on a bug/RFE isn''t available.Which should include the RE, the person being sponsored, etc. (again, as was mentioned last time this was brought up) Perhaps even the ability to request a sponsor via that means, if one is logged in.> 5. External users are effectively shut out of the bug/RFE database. It > should be possible for a (properly authorized) external user to both > update a bug status, and/or take ownership of the bug/RFE.and comment on bugs, update bug information, etc, without having to ask a kindly Sun person to do so for us (though all of those who have done so deserve commending). I''m not sure taking ownership (as RE) is sensible until such a time as the gate is writable, but at the very least a way to flag your interest in it.> 6. A better community-centric bug/RFE prioritization method needs to be > developed.I''m not at all sure how this could work, a look at most public-writable bug databases tends to show rampant and gross misuse of such features. "It affects *me*, of course it''s high priority!".> 7. Bug/RFE bounties need to be considered, along with a method of > funding and payout for themTotally unrelated to b.o.o sucking, but perhaps a good idea. 9. The ability to add oneself to an interest list, and get notification of bug updates. -- Rich. _______________________________________________ website-discuss mailing list website-discuss@opensolaris.org
Karyn Ritter
2007-Jan-10 16:24 UTC
[website-discuss] Re: [zfs-discuss] Priorities (moving forums...)
Sorry I didn''t jump in sooner... Richard Lowe wrote:> Erik Trimble wrote: > >> Please refer all followups to this thread over to the >> website-discuss@opensolaris.org list. > > > > >> >> On Fri, 2006-06-23 at 11:27 -0700, Stephen Hahn wrote: >> >>> * Erik Trimble <Erik.Trimble@sun.com> [2006-06-23 11:15]: >>> >>>> It is a good start (yes, I know it''s an interface to Bugster, just as >>>> the Java one I pointed out is too - in fact, it''s probably the same >>>> code). And, I''m certainly not complaining about how well people have >>>> been taking to and addressing bugs. >>>> >>>> However, there are some significant shortcomings with the interface >>>> that >>>> need to be fixed. And, yes, this is true w/r/t the OpenSolaris >>>> community >>>> as a whole. Basically, the problem is that the OpenSolaris portal >>>> itself is extremely primitive, and really needs a big overhaul to make >>>> the information we have easily accessible in a coherent manner. >>> >>> Please come to either of website-discuss or tools-discuss and share >>> your thoughts for improvement (or at least de-primitivization). >>> >>> >>>> And, in addition, the bug portal isn''t really useful for helping manage >>>> external (to Sun) contributors work. And it doesn''t given any real >>>> insight into who''s working on what, and what schedules might be. >>> >>> I am not sure whether you are commenting on the lack of publication >>> from the internal database (which may have this information), or the >>> lack of this information more generally. >>> >>> - Stephen >> >> >> >> As several others have pointed out, the current Bug/RFE interface is >> seriously broken for non-Sun users, and is missing quite a bit of >> functionality (both in the interface and in the data being stored) even >> for internal Sun folks. >> >> >> Off the top of my head: >> >> 1. The categories for bug submission and searching really need to be >> rethought. At the minimum, the search function should probably be more >> in line with the various communities on OS.org. That is, you probably >> should have main categories which line up with each of the O.S. >> communities, with subcategories being more specific. > > > cat/subcat when searching should be the *real* category and subcategory, > What you suggested would be a nice extra, but is no replacement for > allowing this to be based on what is, after all, the real information. >There are two problems with this: 1. There isn''t a 2-layer search as part of b.o.o. (meaning the ability to select a bug category to search and/or a subcategory of the category you selected. 2. Our categories and subcategories are kinda hard to figure out. I would be OK with matching them, but we did it this way to make the searches broad enough that people would be able to find the bug you''re looking for. Perhaps I''m overestimating how frustrating it would be to have to try multiple searches in order to find the bugs you''re looking for (or I''m underestimating how frustrating the broad search is). If you all think this should change, let me know. This isn''t planned for the current update of b.o.o., but we can put something on the roadmap if it makes sense.>> >> 2. Viewing bugs is a mess - access varies widely across external and >> internal users, bugs aren''t consistently found/displayed, etc. > > > To expand. More fields need to be visible. We''re all aware of why this > isn''t done, and the problems involved, I believe. But a solution needs > to be found to at least display such fields as Evaluation, which fairly > often (I believe) contain useful information. >Unfortunately, the Evaluation field also contains confidential information. We have proposed updates to our bug tracking application to be able to make some of these fields public when there is no confidential information, but I fear we won''t be able to make any/many updates to it at this point.> Comments, and the ability to add same would also be good, but perhaps > even more problematic. >Comments definitely have confidential information.> As mentioned in the last discussion on this topic, ceasing to mangle > Status would be a fine start, even. > > (and teaching the email mangler to stop mangling device paths and > similar would deal with something that, while perhaps trivial, annoys > the hell out of me) :) > >> 3. There is no development schedule information stored/available. e.g. >> when a particular Bug/RFE is expected to be fixed/included. > > > > >> 4. Who is working on a bug/RFE isn''t available. >We''re making progress on this set. I don''t have a firm schedule yet, but we should have a preliminary release in July. There is still some work to be done, but we need to find another contractor to do the rest of the work. My hope is that you all will have more/different comments when we roll the new version out. Here''s what is being fixed: * The Keywords field will be searched and displayed. * Real State will be displayed (e.g., Dispatched). I think we''ll also be displaying the Sub-State, but that was a late addition so I''m not positive (e.g., "Status: Closed", "Substatus: Will Not Fix"). * Additional fields being displayed are "Commit to Fix," "Fixed in" (build), "Last Update Date" and "Responsible Engineer."> > Which should include the RE, the person being sponsored, etc. > (again, as was mentioned last time this was brought up) > > Perhaps even the ability to request a sponsor via that means, if one is > logged in. >This is the next generation of functionality: our "workflow" tools.>> 5. External users are effectively shut out of the bug/RFE database. It >> should be possible for a (properly authorized) external user to both >> update a bug status, and/or take ownership of the bug/RFE. > > > and comment on bugs, update bug information, etc, without having to ask > a kindly Sun person to do so for us (though all of those who have done > so deserve commending). > > I''m not sure taking ownership (as RE) is sensible until such a time as > the gate is writable, but at the very least a way to flag your interest > in it. >This is all included in our proposal to improve our bug tracking software, but again I''m not sure it will get done. More likely we''re going to have to build abstraction tools to display the appropriate information and act as an interface to the bug database.>> 6. A better community-centric bug/RFE prioritization method needs to be >> developed. > > > I''m not at all sure how this could work, a look at most public-writable > bug databases tends to show rampant and gross misuse of such features. > "It affects *me*, of course it''s high priority!". > >> 7. Bug/RFE bounties need to be considered, along with a method of >> funding and payout for them > > > Totally unrelated to b.o.o sucking, but perhaps a good idea. > > 9. > The ability to add oneself to an interest list, and get notification > of bug updates. >This is also covered in our proposal. The issue with the current interest list functionality is that it sends *all* fields as part of the update notification. Meaning that confidential information is sent along with non-confidential information. We are trying to get some kind of RSS-like capabilities built into b.o.o., and we hope that will take care of lots of the problems. Unfortunately, that will be work for the next contractor. - Karyn _______________________________________________ website-discuss mailing list website-discuss@opensolaris.org
Richard Lowe
2007-Jan-10 16:24 UTC
[website-discuss] Re: [zfs-discuss] Priorities (moving forums...)
Karyn Ritter wrote:> Sorry I didn''t jump in sooner... > > Richard Lowe wrote: >> Erik Trimble wrote:[snip]>>> >>> >>> >>> As several others have pointed out, the current Bug/RFE interface is >>> seriously broken for non-Sun users, and is missing quite a bit of >>> functionality (both in the interface and in the data being stored) even >>> for internal Sun folks. >>> >>> >>> Off the top of my head: >>> >>> 1. The categories for bug submission and searching really need to be >>> rethought. At the minimum, the search function should probably be more >>> in line with the various communities on OS.org. That is, you probably >>> should have main categories which line up with each of the O.S. >>> communities, with subcategories being more specific. >> >> >> cat/subcat when searching should be the *real* category and subcategory, >> What you suggested would be a nice extra, but is no replacement for >> allowing this to be based on what is, after all, the real information. >> > There are two problems with this: > > 1. There isn''t a 2-layer search as part of b.o.o. (meaning the ability > to select a bug category to search and/or a subcategory of the > category you selected. > > 2. Our categories and subcategories are kinda hard to figure out. I > would be OK with matching them, but we did it this way to make the > searches broad enough that people would be able to find the bug > you''re looking for. Perhaps I''m overestimating how frustrating it > would be to have to try multiple searches in order to find the bugs > you''re looking for (or I''m underestimating how frustrating the > broad search is). >I don''t think you should *have* to specify cat/subcat when searching, but being able to if you choose seems a good idea. Looking at the current list of "categories", and how they map, The majority of them map to a single category only, several seem they just plain ol'' shouldn''t be there, and there''s still the potential for overlap between several of them even as they stand.>>> >>> 2. Viewing bugs is a mess - access varies widely across external and >>> internal users, bugs aren''t consistently found/displayed, etc. >> >> >> To expand. More fields need to be visible. We''re all aware of why >> this isn''t done, and the problems involved, I believe. But a solution >> needs to be found to at least display such fields as Evaluation, which >> fairly often (I believe) contain useful information. >> > Unfortunately, the Evaluation field also contains confidential > information. We have proposed updates to our bug tracking application to > be able to make some of these fields public when there is no > confidential information, but I fear we won''t be able to make any/many > updates to it at this point. > >> Comments, and the ability to add same would also be good, but perhaps >> even more problematic. >> > Comments definitely have confidential information.We all know that this is currently the case, the larger point is that this functionality is important, and that a solution to present it to the world at large needs to be found.>> >>> 4. Who is working on a bug/RFE isn''t available. >> > We''re making progress on this set. I don''t have a firm schedule yet, but > we should have a preliminary release in July. There is still some work > to be done, but we need to find another contractor to do the rest of the > work. > > My hope is that you all will have more/different comments when we roll > the new version out. > > Here''s what is being fixed: > > * The Keywords field will be searched and displayed.>> * Real State will be displayed (e.g., Dispatched). I think we''ll also > be displaying the Sub-State, but that was a late addition so I''m not > positive (e.g., "Status: Closed", "Substatus: Will Not Fix"). > > * Additional fields being displayed are "Commit to Fix," "Fixed in" > (build), "Last Update Date" and "Responsible Engineer."Sub-State is show for closed CRs as of now, so I''d assume that would stay. The rest is good to hear. :)>> >> Which should include the RE, the person being sponsored, etc. >> (again, as was mentioned last time this was brought up) >> >> Perhaps even the ability to request a sponsor via that means, if one >> is logged in. >> > This is the next generation of functionality: our "workflow" tools.Ok.>>> 5. External users are effectively shut out of the bug/RFE database. It >>> should be possible for a (properly authorized) external user to both >>> update a bug status, and/or take ownership of the bug/RFE. >> >> >> and comment on bugs, update bug information, etc, without having to >> ask a kindly Sun person to do so for us (though all of those who have >> done so deserve commending). >> >> I''m not sure taking ownership (as RE) is sensible until such a time as >> the gate is writable, but at the very least a way to flag your >> interest in it. >> > This is all included in our proposal to improve our bug tracking > software, but again I''m not sure it will get done. More likely we''re > going to have to build abstraction tools to display the appropriate > information and act as an interface to the bug database. > >> 9. >> The ability to add oneself to an interest list, and get notification >> of bug updates. >> > This is also covered in our proposal. The issue with the current > interest list functionality is that it sends *all* fields as part of the > update notification. Meaning that confidential information is sent along > with non-confidential information.From the sound of it, this larger proposal seems to be the way things need to go. i.e., actually making the system usable for those of us outside Sun, rather than making it merely less annoying, if still read-only and largely incomplete. -- Rich. _______________________________________________ website-discuss mailing list website-discuss@opensolaris.org
Karyn Ritter
2007-Jan-10 16:24 UTC
[website-discuss] Re: [zfs-discuss] Priorities (moving forums...)
Richard Lowe wrote:> Karyn Ritter wrote: > >> Sorry I didn''t jump in sooner... >> >> Richard Lowe wrote: >> >>> Erik Trimble wrote: > > > [snip] > >>>> >>>> >>>> >>>> As several others have pointed out, the current Bug/RFE interface is >>>> seriously broken for non-Sun users, and is missing quite a bit of >>>> functionality (both in the interface and in the data being stored) even >>>> for internal Sun folks. >>>> >>>> >>>> Off the top of my head: >>>> >>>> 1. The categories for bug submission and searching really need to be >>>> rethought. At the minimum, the search function should probably be more >>>> in line with the various communities on OS.org. That is, you probably >>>> should have main categories which line up with each of the O.S. >>>> communities, with subcategories being more specific. >>> >>> >>> >>> cat/subcat when searching should be the *real* category and subcategory, >>> What you suggested would be a nice extra, but is no replacement for >>> allowing this to be based on what is, after all, the real information. >>> >> There are two problems with this: >> >> 1. There isn''t a 2-layer search as part of b.o.o. (meaning the ability >> to select a bug category to search and/or a subcategory of the >> category you selected. >> >> 2. Our categories and subcategories are kinda hard to figure out. I >> would be OK with matching them, but we did it this way to make the >> searches broad enough that people would be able to find the bug >> you''re looking for. Perhaps I''m overestimating how frustrating it >> would be to have to try multiple searches in order to find the bugs >> you''re looking for (or I''m underestimating how frustrating the >> broad search is). >> > > I don''t think you should *have* to specify cat/subcat when searching, > but being able to if you choose seems a good idea. > > Looking at the current list of "categories", and how they map, The > majority of them map to a single category only, several seem they just > plain ol'' shouldn''t be there, and there''s still the potential for > overlap between several of them even as they stand. >Actually, most of the "Category" listings on the b.o.o. page correspond to several Bugster (our bug tracking application) categories. For example: b.o.o. Category Bugster category --------------- ---------------- Solaris Kernel fruid rsm kernel It is true that most of the non-ON categories have a 1:1 mapping. I know that the JDS folks worked hard to make that happen before their bugs were made available. In those cases, the name of the "Category" on b.o.o. is basically the same as what is available in Bugster.>>>> >>>> 2. Viewing bugs is a mess - access varies widely across external and >>>> internal users, bugs aren''t consistently found/displayed, etc. >>> >>> >>> >>> To expand. More fields need to be visible. We''re all aware of why >>> this isn''t done, and the problems involved, I believe. But a >>> solution needs to be found to at least display such fields as >>> Evaluation, which fairly often (I believe) contain useful information. >>> >> Unfortunately, the Evaluation field also contains confidential >> information. We have proposed updates to our bug tracking application to >> be able to make some of these fields public when there is no >> confidential information, but I fear we won''t be able to make any/many >> updates to it at this point. >> >>> Comments, and the ability to add same would also be good, but perhaps >>> even more problematic. >>> >> Comments definitely have confidential information. > > > We all know that this is currently the case, the larger point is that > this functionality is important, and that a solution to present it to > the world at large needs to be found. >Agreed. I just wanted to make sure everyone understood the shorter and longer term possibilities.>>> >>>> 4. Who is working on a bug/RFE isn''t available. >>> >>> >> We''re making progress on this set. I don''t have a firm schedule yet, but >> we should have a preliminary release in July. There is still some work >> to be done, but we need to find another contractor to do the rest of the >> work. >> >> My hope is that you all will have more/different comments when we roll >> the new version out. >> >> Here''s what is being fixed: >> >> * The Keywords field will be searched and displayed. > > > > >> * Real State will be displayed (e.g., Dispatched). I think we''ll also >> be displaying the Sub-State, but that was a late addition so I''m not >> positive (e.g., "Status: Closed", "Substatus: Will Not Fix"). >> >> * Additional fields being displayed are "Commit to Fix," "Fixed in" >> (build), "Last Update Date" and "Responsible Engineer." > > > Sub-State is show for closed CRs as of now, so I''d assume that would > stay. The rest is good to hear. :) > >>> >>> Which should include the RE, the person being sponsored, etc. >>> (again, as was mentioned last time this was brought up) >>> >>> Perhaps even the ability to request a sponsor via that means, if one >>> is logged in. >>> >> This is the next generation of functionality: our "workflow" tools. > > > Ok. > >>>> 5. External users are effectively shut out of the bug/RFE >>>> database. It >>>> should be possible for a (properly authorized) external user to both >>>> update a bug status, and/or take ownership of the bug/RFE. >>> >>> >>> >>> and comment on bugs, update bug information, etc, without having to >>> ask a kindly Sun person to do so for us (though all of those who have >>> done so deserve commending). >>> >>> I''m not sure taking ownership (as RE) is sensible until such a time >>> as the gate is writable, but at the very least a way to flag your >>> interest in it. >>> >> This is all included in our proposal to improve our bug tracking >> software, but again I''m not sure it will get done. More likely we''re >> going to have to build abstraction tools to display the appropriate >> information and act as an interface to the bug database. >> >>> 9. >>> The ability to add oneself to an interest list, and get notification >>> of bug updates. >>> >> This is also covered in our proposal. The issue with the current >> interest list functionality is that it sends *all* fields as part of the >> update notification. Meaning that confidential information is sent along >> with non-confidential information. > > > > From the sound of it, this larger proposal seems to be the way things > need to go. i.e., actually making the system usable for those of us > outside Sun, rather than making it merely less annoying, if still > read-only and largely incomplete. >Definitely. b.o.o. will have to get us through for a bit, but none of us think it is a good long-term solution. - Karyn _______________________________________________ website-discuss mailing list website-discuss@opensolaris.org