Re: [cbi-dev] Criteria for Platform team to use CBI

[David M Williams <david_williams@xxxxxxxxxx>]

Igor,

I think Paul covered it all in his response (far better than I ever could
have! :)  but, yes, map files are
not a requirement in and of themselves. Hence, that first item should (now)
probably read something like

> Build the master feature that we use to construct our bundles from the
> map files (or similar mechanism) of an existing build ...

Maybe already covered in Paul's response (or maybe its obvious for other
"how to do" with new system and Git) but the other function
that map files are/were sometimes used for is for a developer/committer to
be able to check out the exact source
into their workspace of exactly what was built for some particular
build ... such as to figure out some bug that was introduced in a build but
maybe is not
reproducible from HEAD ... ugh, I mean Master :)

Thanks for helping us all be clearer.







From:	Igor Fedorenko <igor@xxxxxxxxxxxxxx>
To:	cbi-dev@xxxxxxxxxxx,
Date:	03/16/2012 08:40 AM
Subject:	Re: [cbi-dev] Criteria for Platform team to use CBI
Sent by:	cbi-dev-bounces@xxxxxxxxxxx



David,

Can you clarify if use of map files is a requirement by itself or the
goal here is to have reproducible build and mapfiles is one possible way
to achieve this goal?

--
Regards,
Igor

On 12-03-15 11:54 PM, David M Williams wrote:
>
>
> I'm not the original author of this list ... but I do agree with it, and
I
> am (re?) posting it here for discussion and documentation.
>
> Kim Moir original proposed this list, and in talking to her as she
prepares
> to leave and transition responsibilities, I asked if/when/where this list
> was ever published? I'd seen it in some e-mail notes (and I know at least
> some of you have too) but I could not recall where else it might have
been
> published, mailing lists? wiki?  She thought it had been, but, could not
> find it, so, I just to be sure it is "out there in the open".
>
> This is the current thinking of what the CBI must do to provide (and
show)
> the same quality build that is currently being produced by the platform
> team.
>
> So, apologies if I'm duplicating something, but wanted to be sure to
> capture this (before Kim leaves) in case it was not yet published
> somewhere.
>
> Discussion welcome. Perhaps some items should be added? amended?
clarified?
>
> Thanks, Kim, for providing this starting point.
>
> <quote>
> Criteria
> 1) Build the master feature that we use to construct our bundles from the
> map files of an existing build, for instance a milestone build.  You
can't
> compare two builds just from the master branch as the content is fluid.
> 2) Build the appropriate platform zips for LTS + all products and
features
> that are submitted to Juno.  This includes Equinox features.
> 3) No compile errors, same compile warnings as regular build.
> 4) Run all our JUnit tests. They should have the same results as the
> regular platform build.
> 5) Run a binary comparator against the bundles to ensure that they are
the
> same binary content as the regular bundles, once all the versions and
> qualifiers are the same. There is a p2.mirror Ant task for this purpose.
> 6) The bundles should have the same major.minor.service.qualifier as the
> bundles that result from the regular build.  My understanding is that
Tycho
> produces bundles with unique versions each build.  This is not acceptable
> as it forces the user to spuriously download bundles where the content is
> the same.  In an effort to be good Eclipse citizens and reduce our
> bandwidth utilization we only push new bundles to our repo when the
content
> has actually changed.
> </quote>
>
>
>
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev