That is not so black and white.
Recently we have recieved permission to publish kernel code at a level that was not even imaginable before, but there are still certain areas - which i cannot mention for obvious reasons - that are still considered to be a marketing advantage and therefore cannot be published.

As you can immagine, bugs are not really so easy to partition. Consider a reporter or beta tester reporting a bug on component A which is open, but further analysys showing that it belongs to component B, which is closed.
What happens to the bug? does it disappear? does it get closed till component B is published as well?

And if the bug is assigned originally to component B, but then it is discovered to belong to component A, what happens to all the previous discussion? Does it get censored?

Or, even worse, bug in component X, from a previous sw release is obsoleted by the fact that component X is going to be dropped/replaced but that is not public yet. What should we do?

From my point of view it would be much simpler if there was _one_ bugzilla system, open to everybody, where i could debate anything regardless of who might be seeing it.

But, coming to reality, I have already stated this several times internally, and the problem is that the people who enforce certain closedness are the same ones who also support the external bugzilla and ask developers for more partecipation.

I am not going to solve the inconsistency in their behavior on their behalf.

Especially considering the tight schedules we are already required to cope with, I am not going to ask the people working for me to take the extra effort of self censor themselves while trying to do PR with the community and simultaneously not ruining the marketing strategy.

It's not their job and I don't see why they should take this unnecessary risk upon themselves.

Once we can speak freely about everything, we'll try to do it.