On Tue, 2007-08-07 at 08:25 +0200, Milan Jurik wrote: > Hi Matthew, > > Kaiwai Gardiner pÃÅ¡e v út 07. 08. 2007 v 15:36 +1200: > > On Mon, 2007-08-06 at 20:09 +0200, Milan Jurik wrote: > > > Hi Matthew, > > > > > > I know I'm not right man who should answer you, as I'm from Sun... But > > > look at it from another perspective: > > > > > > V po, 06. 08. 2007 v 19:18, Kaiwai Gardiner pÃÅ¡e: > > > > Agreed, but at the same driver - are drivers *truely* that secret? I > > > > mean, wpi for 3945 was developed in 'secret' - why? what possible loss > > > > of competitive advantage would it yield? looking at it from my angle, > > > > all I see are positives by way of consumers actually seeing and knowing > > > > that Sun are making/porting drivers to Solaris. > > > > > > > > > > Are you sure that Sun employees had access to 3945 development except > > > the developer of it? The most of them didn't know about it. And it is > > > way how distributed development happens - somebody (or some team) is > > > working on something till point it is "compilable" or "usable" or just > > > "publicable". The level of this point is on the developer decision, as > > > usual in open source world. Some developers are publishing all their > > > steps, some are publishing something usefull for users. You had the > > > access to source code of wpi at the same time as the most of Sun > > > employees. Today you can find on bugs.opensolaris.org the responsible > > > engineer for all accepted RFEs, why not to contact him if you want to > > > help with development and/or testing of some particular RFE? > > > > BUt at the same time - if the 'community' knew that wpi was being worked > > on - Sun might have actually found people helping port it to Solaris :-) > > > > A small hear-ye hear-ye would have been on order. > > > > But this happend, the responsible engineer took related RFE and you > could see that on bugs.opensolaris.org. I agree with one thing - bugster > is very good tool, but its public interface is not very useful in case > that you want to monitor some CR.
Hence my leaning towards Bugzilla - people give it a hard time but it is easy to keep track of favourite bugs etc. etc. Much more 'collabortative' - you can actually update submissions etc. etc. all of that should be available on the bugster. > > > And I don't know why File Events Notification API - PSARC/2007/027 is > > > not public. You can see who made the putback - ask him, maybe he is not > > > reading this list. > > > > Its very hard to know when there is no name attached to the put back as > > far as I see. > > > > http://mail.opensolaris.org/pipermail/onnv-notify/2007-April/007227.html > > -> 6381975 solaris need centrino ipw3945 wifi support > > http://bugs.opensolaris.org/view_bug.do?bug_id=6381975 But these are hardly 'visable' forms of communication; its like saying, 'yes, there is documentation, read the source code'. > -> now you know ;-) > > And I think that Brian is very active even in community to help people > with this driver :-) He just worked hard to release something and even > at that time he was ready to communicate with those who wrote e-mail to > him (I know it :-) ). Then maybe its the opensolaris.org website maintainers not willing to create some buzz about what is being worked on. > > > > Things should be merged into the public tree, just like they're merged > > > > inside the company. Everything that occurs inside Sun should occur at > > > > the same time on the other side - if a case log as been updated, then it > > > > should be accessible to the public. > > > > > > > > > > But wpi wasn't merged to Sun tree significantly sooner (it tooks few > > > minutes, that sync between ON gate inside and outside). The developer > > > worked on his source code in his own workspace. As usual. > > > > Would it be better to put documentation out there before the code? > > > > That's typically PSARC and sometimes updates in Bugster. E.g. manpage is > written after driver completition. Which docu? The SPARC information before putting the code in. When it appears on the ONNV change, I want to be able to read about it straight away. > > > > Its all about transparency in the development process; and if it means > > > > that developers think out aloud on ideas - I'd sooner see Sun > > > > programmers conduct regular brain farts on a blog and know there is some > > > > cranium activity about future Solaris development than just sitting on > > > > the side lines praying something is occurring in the deep crypt of Sun. > > > > > > > > > > Did you look at RFEs? Did you look at PSARCs? Did you look at projects > > > on opensolaris.org? And can you show me some really big project where > > > all developers are informing community about their actual work and > > > future plans? > > > > > > Please, leave the decision about their openness on developers. Some > > > prefer public development (lots of Sun employee), some are working in > > > their own workspaces (lots of Sun employee). > > > > > > You want just big amount of paperwork from us ;-) I hope the community > > > is not my second manager asking for weekly reports... > > > > Its about communication - I'm generally not a person who likes to > > communicate anything with anyone - I generally speaking keep people on a > > 'need to know' basis - but at the same time, there is a need to inform > > the community on what is happening. > > > > Tell the community what they're working on - and shock horror, they > > might actually find that a few of the great unwashed might actually be > > interested in contributing. > > > > Look at opensolaris.org, do you think that Sun employees are not doing > it in many cases? :-) I know some projects on opensolaris, which are > done on public base fully. And I know that some are very active in > communication, some not and not only from Sun, frequently they look like > to be just pushed on public space and public space ignores them. But it > is improving. You cannot build "community" just waiting on some orders > or giving them. > > And it is really not only about one way communication, try to contact > people from community and ask them about their work status or if you can > help him. Monitor all sources of informations (yes, some are very hard > to monitor now, but people are trying to improve some ways and/or start > many things from scratch). Be pro-active and not only on > opensolaris-discuss list, which is so "huge" today. This will help > all :-) Communication doesn't have to go overboard, but a quick, 'this what we're doing now' would suffice - atleast show there is some pulse in the body - I go past parts of opensolaris.org and wonder if any of the people involved are alive because its so quiet. Matthew
_______________________________________________ opensolaris-discuss mailing list [email protected]
