Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] release requirements discussion

On 19 Sep 2011, at 14:43, Jesse McConnell wrote:

> Well FWIW I only think the orbit one really applies.  The no harm one
> to me means that your not going out of your way to make life difficult
> for another project, not that your proactively testing to make sure
> that other projects work correctly on your system.

Agreed.

> 
> the orbit one is a stickler though, I know they want everything 3rd
> party pulling from orbit, but I thought that was an incremental goal
> of yours right?

I'd kind of lost track of that as a goal because of our build system's inability to consume stuff directly from Orbit. Maybe that's what we should focus on as an enabler (pardon my manager-speak).

But I guess the motivations behind the Orbit requirement are (a) to ensure IP cleanliness and (b) to avoid version skew across the release train, which I suspect generally means the IDE.

(a) is fine since we do that for any release.

(b) is perhaps less relevant for a runtime project as we've discussed in the past.

I wonder if you could dig into the Orbit requirement and see what really lies behind it? We might be able to satisfy the spirit of the requirement if not the letter.

> Get the slew of dependencies you pulled in from
> springsource into svn for the short term and then transition off of
> them over time as they get into orbit or have suitable replacements.

For the record, we keep dependencies in Amazon S3 and download them using Ant/Ivy at build time.

> 
> cheers,
> jesse
> 
> --
> jesse mcconnell
> jesse.mcconnell@xxxxxxxxx
> 
> 
> 
> On Mon, Sep 19, 2011 at 08:23, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
>> Hi Jesse
>> 
>> There are two rows of the grid that would have a massive impact if Virgo had to implement them:
>> 
>> * "Re use" which requires all 3rd party dependencies to be consumed from Orbit. Virgo would have to get many tens of dependencies into Orbit and would need to change build process to consume them directly from Orbit.
>> 
>> * "Do no harm" requires project to work together in any combination. We don't have the necessary QA resources given the number of RT projects that might want to run on Virgo.
>> 
>> Some of the other rows would take significant effort, but nothing like the two above.
>> 
>> (As for the rows you pick out below, I think Virgo is pretty much covered already. Some may not be done quite the way Eclipse would prefer and some are 'n/a', but those are details really.)
>> 
>> Regards,
>> Glyn
>> PS. Sorry for the delay in responding - the silly season is now officially over, at least for me.
>> 
>> On 1 Sep 2011, at 21:05, Jesse McConnell wrote:
>> 
>>> On the last call I said that I would go through the tracker that we
>>> did for jetty and list of the things that I had basically gone through
>>> and put 'n/a' on as they really didn't apply to our project, or we
>>> just flat out do things differently such that is made no sense.
>>> 
>>> These are basically the options you see on the following grid.
>>> 
>>> http://eclipse.org/indigo/planning/SimultaneousReleaseGrid.php
>>> 
>>> I don't see adding n/a as a particularly onerous task on here but some
>>> the others are pretty important to the release process and do
>>> represent some extra work.
>>> 
>>> API
>>> Message Bundles
>>> Capabilities
>>> Support Translations
>>> Excel in NL Support
>>> Branding
>>> Usability
>>> Enable Use with All Languages
>>> Ramp Down Planned and Defined
>>> Accessibility
>>> 
>>> Glyn, do you want to look through the list on the grid and list out
>>> what bullets you see as potentially most time consuming for virgo?
>>> then we can have some group discussion on how to make them easier,
>>> following that take it to the david williams for some feedback.
>>> 
>>> cheers,
>>> jesse
>>> _______________________________________________
>>> rt-pmc mailing list
>>> rt-pmc@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>> 
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>> 
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc



Back to the top