As me and timeless discussed in our talk, if you state a project is open , follow the statement. If the core base as not intended to be an end user platform, and is defined as an LFS project, why does it contain CSI stuff in a linux foundation bugzilla ?
I propose each "client" "customer" "vendor" whatever has his own bugzilla or issue tracking pertinent to his "derivative" to not taint the open source meego.com. Customer sensitive information has one place and only one place - in customer's internal issue tracking system. If they want something fixed (with) upstream, they should have the person (the developer, PM whatever ) affected by the bug, report it on the open source bugzilla and work there with meego.com - the upstream until it is resolved. As someone following the open source meego distro, I couldn't care less about specific customer's issues that have no relevance or origination in the open source code base in its original form, unless I'm a consultancy doing custom development services on MeeGo, for which the mentioned down applies the same. bugs.meego.com should have no "permission denied" bugs. The process for re-reporting the issue from a "customer" (onto an open source bugzilla without CSI residual) should be prompt enough and perhaps we should anchor it in a "Working with upstream MeeGo guidelines" ? I've done this with projects like RSysLog, CouchDB , CouchDBKit, Ubuntu, GNOME and many more. I think that could be a solution to this issue? Or could this create a different problem of issues not reported even thought they originate and/or affect the core pristine code base? -Sivan On Thu, Oct 28, 2010 at 6:12 PM, Dave Neary <dne...@maemo.org> wrote: > Hi, > > eric.le-r...@nokia.com wrote: >>> Usually that reason is "security issue" or "customer sensitive >>> information". >>> >> This seems to fall under the "csi" category probably. > > The unfortunate thing for me is "this will increase in the near future > before it gets better". Is there a possibility of putting in place some > kind of process whereby the bugs can be public & sanitised (without any > CSI) and any super-zoomed surveillance photos, ballistic reports, DNA > profiles, fingerprint searches and other CSI stuff can be somewhere > else? (excuse my attempt at levity - hope it doesn't get lost in > cultural translation!) > > Having closed bugs is one thing - planning to have more is another. > >>> But like you said, there should be a way to request access for people >>> who need to know. >>> >> As far as I can tell, this situation is exceptional and we should return to >> normal very soon. >> I completely understand the frustration and actually share it... > > a suggestion would be to have a "Reason" field which would be required > when closing a bug to public - at least that way people would know why > the bug was closed off. Reasons could be "confidential information", > "Security issue" or "Oops, I checked the checkbox by mistake" :) > > Cheers, > Dave. > > -- > maemo.org docsmaster > Email: dne...@maemo.org > Jabber: bo...@jabber.org > > _______________________________________________ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines > _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
