Difference between revisions of "CBI/Jan10 2012"

Latest revision as of 09:11, 10 May 2017

Meeting date/time

• January 10, 2011 @ 10am EST
• Andrew's conference bridge

In attendance

Markus Knauer, Denis Roy, Andrew Overholt., Kim Moir, David Williams, Paul Weber, Igor Fedorenko, Wayne Beaton, Andrew Ross. Alex Kurtako?

Tentative Agenda

• Those that tried the build, compare notes
• Packaging and branding
• Testing
• Pushing & pulling to/from: Orbit/Maven.eclipse.org/downloads.eclipse.org/LTS
• Revisit: Are we building everything we need to be for platform?
• How we should handle platform-specific builds like SWT
• Revisit: Do we expect we need map files for the platform build once it's all in git?
• LTS program and a LTS ready definition for projects
• Set a time for the next meeting (same time/day 2 weeks?)

Comparing notes

• Build was easy, quick, etc. for a bunch of people

Packaging

• Paul: proto build should have the same branding as the platform SDK

   - Eclipse product definitions is where the branding comes from
   - Kim offered to send a link with more info.
   - Igor explained that we're asking p2 to install product, need to understand the delta between that and what we need
   - Action Andrew: Raise a ticket & announce on mailing list to keep this discussion going. Doesn't sound serious, but sounds like a bit more to figure it out.

Testing

• Paul: ran the Junit test framework

   - 0 errors, which looks good
   - Something not quite right, wasn't able to generate html output, need to investigate more. (Action: Igor/Paul investigate please)
       Kim: Junit.xsl didn't run correctly?
   - Paul comparing test output, will post results to the list once done

Push and pull

• Andrew asked about overlap between various systems
• Paul: maven instance can't handle p2 today, that's a commercial add-on

   - Can take a p2 repos and turn it into a maven structure but then that wouldn't work for p2 anymore
   - Maven is great for jars, p2 is OSGi bundles for installs with different meta data

• David: Hudson to downloads is a good idea in theory, but not practical today. Stages let projects do what they want

            and aggregate the various outputs to build releases.

• Andrew editorial: This is a good topic for a detailed walk through in another meeting.

Are we building everything we need?

• Paul: Comparison he posted to the mailing list just before the call is 80% of what we build (see mailing list)

         - This is the first level comparison
         - Can't compare qualifiers yet since the qualifiers don't match, they're based on date/time

• Kim: prototype build isn't signed, which is also an issue

        - IBM wanted to minimize downloads, so comparator was important

• Igor: Two related issues, known already

        1) Rebuild historical version, expected output should be the same, same version qualifiers.
        2) 3.8 vs. 3.8.1 - expect to build just what bundles that have changed

• David: There's a third issue

        3) Milestone to milestone build, qualifiers shouldn't change if the code hasn't change
        Building on Kim's comment: It is more than just bandwidth, in a maintenance/support scenario, you can tell what has and hasn't changed.

• Paul:

       Kim, does the final plugin versions contain a list of what PDE built for that? Kim: Yes.
       - So to compare prototype vs. PDE... look at the file?
       - Igor: for each bundle, there are two records. bundle, source bundle. There's 4
       - Paul: For each PDE build,
       - Paul: we don't need to consume this file. This is just a good way to compare what got built thus to compare to what PDE builds.

• Action: Igor to raise a ticket & continue investigating with Kim & Paul's help please?

SWT/ platform specific

• Kim, if LTS needs SWT and platform specific, then Foundation needs the right hardware

   - SWT is built first and stored. PDE build pull is out.
   - SWT team has 14 platforms they support. Pushes into git as binaries.
   - Post-prototype should pull from git just like PDE build
   - In the longer term, build if we need to, esp. for LTS
   - Igor: some build produces DLL's/shared libraries
           another process packages them as Jars
           mentioned he doesn't have experience building the native libraries
           Kim offered to ask someone from SWT to help.
           Igor still thinking about whether Tycho should go this way, or use something else.
           Action: Igor, continue work on previously planned work here. Please raise a ticket if we don't already have one.
           Action: Andrew, Foundation's (inc. CBI/LTS) plans for platform specific components. Raise a ticket.

Map Files

• Andrew asked if we need mapfiles in the future assuming git, is this crazy?
• Paul & Kim:

   - Map file gets the tag & URL/location for checking out the code
   - Paul: so yes, an aggregator git repository + poms can replace the maps (see caveat for 3.8)
       - 4.2 going forward, team has decided on a convention of UTC timestamp of last time that bundle was touched
       - Tycho doesn't currently support that, but maybe it could? Igor: it is possible
       - Paul: then it's possible to get rid of a mapfile BUT...
   - Paul: 3.8 can't really change since the qualifiers would all change if they used UTC timestamp
            Igor: there are qualifiers in the build today that are not timestamp based
            Paul/Kim: e.g. JDT core, SWT esp. needs to pick a number and have it match

• Andrew editorial: No action assigned here, but worth keeping in mind as the platform repositories migrate.

Next meeting

• same time 2 weeks. Andrew R. will send out the invitation.

Anything else

• Kim: - Should CBI & LTS compile against multiple execution environments? It's currently running against 1.6.

   - Igor: Compile & test on each? Compile on one and test on another? Help figure out the requirement.
   - Kim/Paul: we compile & run on the same.
   - Paul/Kim: We need the runtime environment to match what's in the manifest.
   - Igor: It's possible to provide tycho with a map to pick and choose which JRE

• Action: Andrew to raise a ticket to track this.