Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Participation in Helios build?

Oh, one thing I forgot to mention for the translations.

Once we have externalized strings and some NL bundles, we can sign up for Babel:

Community base translations are a good thing :)

On Wed, Dec 9, 2009 at 9:27 AM, Chris Aniszczyk <zx@xxxxxxxxxxxxxxxxx> wrote:
> On Wed, Dec 9, 2009 at 8:47 AM, Sohn, Matthias <matthias.sohn@xxxxxxx> wrote:
>> Chris Aniszczyk <caniszczyk@xxxxxxxxx> wrote:
>>> Once we have a build going, we can add ourselves to the Helios build.
>> For that we need maven 3.0-alpha-5 or newer installed on Hudson to get
>> the Tycho build running there, do you know if that's already available ?
>> Anything else you see missing here ?
> As long as we do signing, I think we will be OK. There is also some
> things around us including "incubation" in the bundle / feature names.
>>> There's also quite a bit of groundwork for us to do to become part of
>>> the train in terms of signing and localization (and other things).
>> Could you provide some pointers on what's ahead here ?
> Yes, here is a brief summary of what needs to be done. Let me try to
> separate things out to what I think we have already and what we don't.
> - Message Bundles. Projects must use Eclipse message bundles unless
> there are technical reasons not to.
> We need to work on this.
> - Execution Environment.
> We should make make sure that we have a
> Bundle-RequiredExecutionEnvironment (BREE) set for our bundles. Now
> that I think about... what version of Java are we targetting? This
> should be reflected in the BREE. We should also use PDE API Tools'
> execution environment validation to make sure we don't call any Java
> 6.0 methods if we are targetting Java 5.0 :)
> Signing. Projects must use signed plugins using the Eclipse certificate.
> - We need to make sure that we do this as part of our build.
> Optimization. Projects must optimize their p2 repositories to reduce
> bandwidth utilization and provide a better install and update
> experience for users.
> - We should ensure that we could run pack200 against our build... not
> sure if Tycho supports this out of the box.
> - Communication: Build team members (or their designated alternates)
> from each project may be asked to provide direct communication
> channels: phone, mail, IM, IRC and at least one build team member must
> be "on call" during the milestone integration periods.
> We do some of this. I sent an email about this earlier this year. I'm
> not sure how to improve on this given people's attitudes.
> - API. Projects should leverage only published APIs of dependencies.
> We do this already from what I've seen. We just should be careful
> about what we declare API and mark other things as x-internal.
> - Version Numbering. Projects must use 4-part version numbers.
> We do this already.
> - OSGi bundle format. All plug-ins (bundles) must use the true bundle form.
> We already do this :)
> - Jarred Bundles. Projects must use jarred plug-ins (with
> unpack=false) unless authorized by the planning council for technical
> exceptions.
> We already do this.
> - Re-use and share common third party jars.
> We need to make sure we do this.
> - Provide p2 repository.
> We will do this as part of our build.
> - Branding. Each major project (as determined by participating PMCs)
> must have an 'About' dialog icon with hover text that displays the
> provider name.
> We do this already
> - Do No Harm. Projects must work together in any combination of any install
> We should meet this requirement already :)
> License text consistency. Use standard forms of license documents so
> it is displayed in the most usable
> - We should meet this already :)
> We should open bugs for things that we don't have.
> Cheers,
> --
> Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
> |

Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465 |

Back to the top