Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev]Galileo Must-do's

Title: Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev]Galileo Must-do's
Feel free to interpret “should do” as “nice to have” in this case.  We decided 2 categories were sufficient, must and should.  If it’s not a P1 == must-do item, then simply close that bug as WONTFIX with what you have below.

- Rich


On 11/14/08 10:36 AM, "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:

Hi Richard,

If I'm not mistaken, the Release Review process just asks me to report about the state of non-code aspects in my project. It doesn't ask me to "design and test for bidi" like one of the "Should have" requirements reads.

I'm fully OK with externalizing Strings into Message bundles since I see it makes sense, it's good citicenship and, most of all, is not much effort. But "designing and testing for bidi" is on a completely different page. It's an enormous effort, it requires experience, it's hard to get the test environments, I'd even say that it requires people who are native speakers of an RTL language. I wonder how I'm assumed to accomplish this in the scope of my project.

I'm not at all against BIDI. I've had some bug reports related to it and tried to help, but without external assistence (by the reporter) or patches provided I'm totally lost. I don't have the expertise for helping here in the slightest way. Proper BIDI support, in my opinion, requires an experienced test and development center. A member who needs BIDI support should set that up and provide BIDI testing, bug reporting, knowledge transfer and assistence for all the projects. Without that, the requirement is totally moot in my opinion. It shouldn't be labelled "should have" but "nice to have" IMO.

I think we've had similar discussions before with respect to integration testing. At one level there comes the point where it goes beyond individual project's scope and capabilities, and the Foundation should strongly think about employing people who do it on behalf of the projects if they want progress in that area.

Cheers,
--
Martin Oberhuber
, Senior Member of Technical Staff,
Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

 


 

From:  eclipse.org-planning-council-bounces@xxxxxxxxxxx  [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of  Richard Gronback
Sent: Friday, November 14, 2008 1:49  PM
To: eclipse.org-planning-council; Cross project  issues
Subject: Re: [eclipse.org-planning-council] RE:  [cross-project-issues-dev]Galileo Must-do's

 
Hi Martin,

Many of the things we’re requiring  are just good Eclipse citizenship items that all projects should be striving  for anyway.  Globalization effort is not only about larger companies or  commercial adopters.  At least 2 of the 3 communities that all Eclipse  projects are supposed to support require this for worldwide consumption.    I see these as Eclipse entry requirements, not only as train  requirements.   See non-code aspects listed on the Release Review  checklist: http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews

I  can imagine a larger company contributing to a smaller project to get it up to  snuff if they are consumers of the project and require it for a commercial  product, for example.  But, I doubt you’ll find a willingness to  contribute for the sake of getting projects on the release train.   Instead, we’ll likely just see smaller projects falling off the train,  or the respective project leads growing their project team to meet the  requirements, and in the process, improving the overall quality/success of  their project.

Best,
Rich




On 11/14/08 7:16 AM,  "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>  wrote:

 
Hi  Richard,

I  fully agree with what you say. I second the idea that participating in the  train may cost something, because you also gain from it. I agree that we  need rules in order to keep consistent as we grow.

But I  do see a potential problem here:

The PC  is comprised of a single representative of each PMC. These representatives  are typically from the larger companies, who can
afford sponsoring  Eclipse to a larger extent (by providing PMC personnel, expensing for travel  to Face-to-face-meetings etc).

These  larger companies are also the ones who are interested in globalization, and  as a matter of fact many of the must-dos have
to do with globalization:  String externalization, Babel, ICU4J just to name few.

Now by  means of the Train, smaller projects (sponsored by smaller companies) get  forced to invest in globalization although they would
normally not need  that because they might be interested in English-only versions of their  products based on Eclipse. It almost seems
that the larger companies  (represented on the PMC's and the PC) take the Train as a vehicle to have  smaller projects do work that only
they benefit from.

I'm in  favor of Rules that can be argued to improve the Eclipse Architecture and  consistency of the projects. I like Capabilities, UI Guidelines,  Branding, Build, Execution Environment, OSGi, New&Noteworthy,  Ramp-down-plan, Orbit. I can also understand Accessibility as a  social responsibility and quality signal of Eclipse. But for rules that  cannot be argued like that, I think that those who  need or gain from a rule (the large ones) should also pay for it  (by contributing to the smaller projects).

Again, I'd like to encourage everyone  interested to participate in my poll:
http://www.doodle.com/64gndycncpksufx9  <http://www.doodle.com/64gndycncpksufx9>  

Cheers,
--
Martin  Oberhuber
, Senior Member of Technical Staff,  
Wind River
Target Management Project Lead, DSDP PMC  Member
http://www.eclipse.org/dsdp/tm

 

 

 
 

From:  cross-project-issues-dev-bounces@xxxxxxxxxxx   [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]  On Behalf Of  Richard Gronback
Sent: Friday,  November 14, 2008 12:32  PM
To: Cross project  issues
Cc:  eclipse.org-planning-council
Subject:  Re: [cross-project-issues-dev]  Galileo Must-do's

 
Each year, we  raise the bar a little on release train  participation.  As I  recall, the main bar-raising items are capability  definitions and  New & Noteworthy pages.  These didn’t seem too  drastic by  members of the PC that agreed to them, but maybe we were wrong (I   certainly hope not).

And to be clear, nobody is forcing  anyone to do  anything.  Participation on the Release Train is  voluntary, but comes at  the cost of agreeing to release at a higher  bar than what is normally required  for releasing as a non-train  project.  There’s not a whip involved here,  but a carrot.   If you’d like to be on the train, there is a cost, that’s   all.

- Rich


On 11/14/08 5:01 AM, "Thomas Hallgren"  <thomas@xxxxxxx>  wrote:

 
 
I miss the good old days when  Open Source  communities were based on the contributions that they  got, where the  contributors were heroes, and the quality of the  resulting product were the  product of their goodwill and skill. I  find that participating in the  Eclipse release train nowadays  involves efforts that are somewhat  overwhelming and that I,  instead of adding valid functionality to the areas  where I  contribute, am forced to implement requirements that brings much   less benefit to the intended user base.

I think that when a  central  management stipulates this many requirements for  individual projects,  there's a high risk that all the fun is taken  out of it. As a contributor,  and even as a project manager, I  loose control. I no longer decide what's  important in my own  domain. I no longer prioritize what to do with the time  I spend on  the projects. Someone else does. A lot of the motivation is   thereby lost, replaced with a whip that forces me to comply with a  strict  set of rules. Was that the intention? I don't think  so.

Don't get me  wrong, I can see that there are benefits  in having a common set of  requirements. I just think it's a tad  too much  now.

Regards,
Thomas  Hallgren



Schaefer, Doug wrote:   
 
 

It'll be  interesting to see what  happens when we get to the Release Review and find  few of us  actually did all the must dos. Unfortunately, the must do's   didn't come with additional contributions and I can't seem to  pull any out  of my, uh, never mind. I see Doom ahead unless a  Christmas miracle  happens.


Doug.

 
 
 

 
 
 

From:  cross-project-issues-dev-bounces@xxxxxxxxxxx   [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]   On Behalf Of Anthony Hunter
 Sent:  Thursday,  November 13, 2008 10:20 PM
 To: Cross  project  issues
 Subject: Re:  [cross-project-issues-dev] Galileo   Must-do's
 

 

Hi Team,   with respect to the questioning of the capabilities as a "must   do":
 
 http://ahuntereclipse.blogspot.com/2008/11/i-just-dont-have-any-capabilities.html
 
and   further comments should go on https://bugs.eclipse.org/bugs/show_bug.cgi?id=252807   
 
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software   Development Manager: Eclipse Open Source Components
IBM  Rational  Software: Aurora / GEF / GMF / Modeling Tools   
 


 
 


_______________________________________________
cross-project-issues-dev   mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  


 
 

_______________________________________________
cross-project-issues-dev   mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

 

_______________________________________________
eclipse.org-planning-council  mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT:  Membership in this list is generated by processes internal to the Eclipse  Foundation.  To be permanently removed from this list, you must contact  emo@xxxxxxxxxxx to request  removal.


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top