Wednesday, March 12, 2008

Standardized Groups Rock for Webmasters AND Projects

A little Eclipse trivia quiz for you today (to make a point). Anyone know which project owns the Eclipse Unix groups below or what they're for?
  • core-variables
  • javafam
  • xsd
Ok, so I already know where all of those belong--I don't know what they're for--but you can see how scripting anything using this data without a complex lookup table (and maintaining the table) is not very easy. See bottom for answers in white on white text. Highlight to see them.

So, additionally, we have 81 projects listed in the Foundation database that don't have any Unix groups at all. Huh? Well what that means is not that they don't have files, but that the files are actually owned by the higher level project. That then starts to get into all kinds of sticky things regarding the Development Process. What project do they really need to be elected to in order to commit those files?

We, as webmasters, get requests saying "Joe is a committer on the XXX project which I'm sure owns these files, but doesn't have access to /cvsroot/technology/YYY/XXX/some_path, so can you add him to the YYY-dev group?" That violates all kinds of rules for development at Eclipse and frustrates projects when we say "No we can't. Please elect him to technology.YYY, which owns the files." If we even know for sure. Then there are hundreds of groups which have nearly completely overlapping membership with other groups. Do most projects need both with just one member different? No, but nobody knows where all the files are used without a data audit, and furthermore no one on the project team has time to straighten that out. Wouldn't it be easier if this were all mapped out and when you wanted someone to get the ability to work on some files you just elected them to the project? Bug 198541 is about solving all of this stuff.

If you're a committer you already ready my note to the list. If you aren't or you don't read mail from that list or you just don't like me ;) you can find it in the handy archive. It's as short-winded as I could make a long-winded subject. Refer to the 125+ comments on the bug if you want to see how condensed the summary is.

So what's my point? Well this could all, in one light, look like a bunch of bureaucracy we're foisting on the projects. Hopefully you'll see it for what it is. Just look into my crystal ball... muahahahaha. But seriously, I really think--and hopefully you're convinced--that this is really going to be great for everybody. We've made it a pretty big initiative at the Foundation and we think the whole community benefits. Happier projects = happier committers = happier members = happier Foundation = less drinking by webmasters.

  • core-variables = eclipse.platform
  • javafam = eclipse.platform
  • xsd = modeling.mdt.xsd


Post a Comment

<< Home