Talk:Infrastructure Problems
I believe this is a good way to keep a running list of things that can be improved w.r.t. the infrastructure.
Would be good to know which things are fixable, and when, vs. inherently unfixable.
e.g. googling of OO.o mailing lists is one of those high priority requests which has been brought up again and again.
Hopefully, this wiki shows up in google!
--Dkeskar, 20051118
Louis' comments
I removed Louis' comments & put them here so we can chew them over properly [ I've also edited some of the highlighted problems out of the pages ]
Comment, LSP: What is the point of this diatribe? Michael: if you have legitimate complaints with the infrastructure, then I urge you to bring them directly to CollabNet. But I also urge you to do some due diligence and determine what is OOo and what is SourceCast. Keep in mind, too, that when we (Sun/CollabNet) designed the ancient version of SourceCast for OOo, many one-offs were committed; these have been perpetuated as SourceCast has evolved (it's now called, btw, CollabNet Enterprise Edition and is at 4.0; we use 2.6). Furthermore, the basic architecture of SourceCast was altered to conform to OOo's requisites. This change affected performance and some elements of usability. For insight into other versions of SourceCast that are more or less at the same version, see, for instance, java.net, jini.org, jxta.org, or sungrid.org. I'll respond to some of your more obvious complaints but I have better things to do. Don't you?
So - the point of this page from my view is multi-fold
- to ensure that these issues are tracked
- to educate other developers as to why things are like they are
- catharsis - these are *acutely* frustrating issues for developers
So - AFAICS SourceCast drives the OO.o infrastructure; I see problems in the OO.o instance of SourceCast and the service provided by it as a legitimate topic of discussion under this 'Infrastructure Problems' page - do you not ? Either way I've changed it to "OO.o's source-cast instance" & included some of your comment in the text.
Wrt. having better things to do - no; as it happens - getting barriers to entry for new developers removed is a personal priority - I have no better way of actually raising the profile of these issues & getting something actually done, and people to take these issues seriously than cataloguing them and pointing out the somewhat comical nature of the failures here (to my mind). The "give the current system a fair trial" argument, is not very compelling on bugs that are multiple years old & still unfixed.
Wrt. the page - I've re-written your comment, pointed out that most of this is fixed in later collab.net products, referenced them etc. any more changes for you required there ?
Comment from Louis Suarez-Potts: I actually have not encountered this behaviour. I do not access OOo from CollabNet but from home, so doubt if my charmed life has to do with my particular location.
So - this is something that developers encounter *daily* and as such, the attitude of "simply because I cannot repeat the problem => the reporter must be decieved / this is not a real issue" is IMHO not a helpful one. I've removed this commented & added a note about network topologies.
Comment, LSP: You are confusing political with site structure. The site structure does not determine the politics of OOo; that was done when the project was incepted, years ago. It can be changed, but and in some projects, it has been. If you wish to change the overall political structure, then bring it before the Community Council, not in a diatribe like this, which is erroneous and misplaced.
So - I agree this is prolly out of place & belongs in my extended to-be-written collab.net rant. However what you write is prima-facia un-true. The site structure certainly determines the politics of OO.o - 'Project Leads' hold special roles, have many special privileges etc. The site structure: number of Projects, & hence the number of leads has a major effect on the politics of OO.o. Anyhow - I removed the unhelpful section of text here.
