Simon Phipps wrote:
>
> On Apr 16, 2007, at 01:13, Shawn Walker wrote:
>
>> On 15/04/07, Alan Burlison <Alan.Burlison at sun.com> wrote:
>>> Glynn Foster wrote:
>>> > FWIW, we tried to do this with GNOME, and found it bloody awful. We
>>> may not have
>>> > done it properly in the first place (and that's more than likely)
>>> but it was a
>>> > real pain trying to sync up the two databases, and we ended up
>>> polluting bugster
>>> > with a whole lot of crap. You'd really want a full time bug master
>>> to keep on
>>> > top of all of this.
>>>
>>> In general this is an exceedingly difficult (impossible?) problem to
>>> solve, I doubt you were doing anything "wrong" - other than trying in
>>> the first place ;-)
>>>
>>> If I suggested we should run two parallel but separate 'master' SCMs for
>>> ON, one inside Sun and one outside, and that we were going to allow
>>> people to simultaneously make changes to either one and then try to glue
>>> it all together into a consistent whole, I'd rightly be told that I was
>>> nuts. Having two bug systems would be no different.
>>
>> Perhaps, but the difference is that all of the code in the OpenSolaris
>> codebase has been audited, etc. Whereas all of the content in the bug
>> database has not. You don't place customer information, confidentially
>> secured materials, etc. into the OpenSolaris code whereas you do with
>> the bug database from what I understand.
>>
>> Despite it being crazy, many other projects have to do exactly this
>> thing. So I think it is inevitable that a way to manage it will have
>> to be found.
>
> I agree with Shawn. The issue here is to recognise the difference
> between Sun's business and the community's work. Sun will continue to
> need a way to track the information flowing from its relationships with
> its paying customers, and that system must be private. Sun's staff are
> then likely to file bug reports with OpenSolaris.
>
> OpenSolaris needs a single, public bug tracking system and Sun then
> needs an internal-use-only "overlay" that allows just the
> relationship-confidential information to be stored and tracked, linked
> to the public bug report that relates to that information.
>
The assumption here is that this needs to be two systems, but I haven't
actually seen that backed up with any kind of reasoning (apologies if I
missed it). Why is a system of ACLs controlling who can see what, as has
been vaguely suggested many times before, not appropriate here?
Sun confidential info could be restricted to Sun people, information
confidential to others, to other people. Without any of the two-system
merging issues.
The possible downsides of two systems seem obvious:
- Merging issues
- The exact same problem we have now, everything hiding out of sight
because of engineering laziness.
Even assuming that there is a real need for two systems, as is being
suggested, I don't think merging issues necessarily apply.
What we'd be looking at is a SubCR (to abuse the term) of Sun-specifics (be
they call records, or whatever else). I'm not immediately able to think of
any critical information that would be shared (but differing) between the
two. The Sun side of this need only be a collection of call records and a
pointer to the real (open) bug. No change made on the Sun side would
propagate outward (by supposed necessity) and no change outside need
propagate inward (because the information is already available, outside,
where it should be).
Again, the possible two-system (or, frankly, N-system, you've all forgotten
other distributors may well want the same thing) merging falls under
"Hamstrung for the needs of SMI", and is something I'm not seeing as a
requirement that should in any way hold back or adjust our choices.
-- Rich
