[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [eclipse.org-architecture-council] Things Committers should know
- From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
- Date: Wed, 25 Feb 2009 17:50:53 +0100
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcmXZwUSdDK9hEfzROencUwTTsApqwAARLaA
- Thread-topic: [eclipse.org-architecture-council] Things Committers should know
> Nope. AFAIK, this isn't captured anywhere.
Hm, that's a problem in my opinion. I think that we shouldn't be
disseminating any information as unstructured "committers should
know" that isn't also available in its preferred structured form.
In other words, if this isn't captured anywhere then we just
found a problem, and it should be captured now. How would we
ever expect new projects to find their information to do the
right thing if that's not done? In this concrete case, who's
job would it be to put that into its structured place?
On another note, on the Eclipse PMC call, McQ just had the
Phoenix / Nova UI that automatically turns all external
links into something that warns users about them being
external. Would that be doable?
> the entry comes from my own recent experience with
> the Examples
What I don't understand here: are projects requested / pushed
to turn components into projects in order to make our
webmaster's work easier, or are we keeping things as-is by
default and projects can opt-in if they want?
I got your note about containers (thanks!), though I personally
think that a simple component -> project change should be
streamlined (simlar to the add-to-orbit / PB-from-orbit CQ's).
I'm still missing a note like "ask your PMC if you want a
new project" that helps interested parties the first step.
On 2nd thought I agree it makes sense that all committers
know this dev.process change.
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member