[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cbi-dev] Criteria for Platform team to use CBI
|
Thanks for posting this David. I too had a copy of Kim's suggestions and
was using it as a guide as we progress in developing the CBI platform
build. At this point, there should be a bug for each of the items. I
suspect many are covered already but it would be worthwhile for others
to scrutinize the list to reconcile against the list of open bugs to
help confirm. We can add details to existing bugs or open new ones as
needed.
On 03/15/2012 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
