[wtp-incubator-dev] Re: Build Signing

[David M Williams <david_williams@xxxxxxxxxx>]

 >> While we're looking at the milestone
build for suitability ... 

Hmmm ... you are supposed to do that before a request
to promote.
Guess that's another thing to learn.

>> Where does that date come from?
> The v* date comes from the date the build was
run.

I think Dave meant to say "not" the date
the build was run? 
(the date on the zip file, is the date the build was
run, though). 

In the features and bundles, the v* dates are the
date from the cvs
tag that is in the map file, as Dave implied. In a
version such as
v201001160736-17Y-BgJ9E99OEhJOJ9, that gobbledygook
after the v*
datetime is a "hash" composed of all parts
of a feature. The idea
being that any small change in a feature, will still
show the
feature as changed ... even if the feature definition
itself didn't
change. All this is built in to the PDE build tasks.

>> This isn't a "problem" really until
somebody reports a bug and can't 
>> easily tell us what version they're using.

There is a function, under Help, About, Installation
Details, Configuration, 
that produces a big listing of all bundles and versions
and other stuff. You'll want to
request this on many bug report, since even if users
tell you they have 
"version M2" of your stuff, you might find
they have it installed with, 
say, the Helios version of the Platform, or have some
extra "interfering" bundles
installed, etc.  Complicated, I know ... we'd
all like better user (and programmer) 
friendly versioning of some sort. But its not done
after years of discussion ... 
because no one has done it yet. 

>> I'm learning, but there always seems to be
another gotcha. 

Same here. Its amazing, isn't it? I hope its as fun
for you as 
it is for me, when not frustrating.

One thing to learn is that there is very little that
happens for
free, or automatically, or perfectly consistently.
That's true of
software development in general, of course, but especially
true for
Open Development. It is important to test early, test
often, and be
very explicit in communications, to the project, and
the community.
I'm sure the fact that your mail isn't getting through
doesn't help.
I hope that is fixed soon.

I can see how you might assume milestone builds to
be "signed
automatically". But, the way things normally
work is that a build is
produced, it is tested to see if it is as expected
and the one that
is desired to be "declared" as the milestone
(or what ever) and then
it is declared. I'm sure you can see how when I was
asked to promote
that build, I also was making an assumption ... that
all that
testing had taken place already and it was just as
you expected. 

One thing that would be helpful to WTP (if not all
of Eclipse) is to
document some of these surprises you find ... so others
might not
hit the same issues, or so we can improve things and
remove the
surprise. You could produce pages on the Eclipse WTP
wiki, or open
bugzillas.

For the specific issue of signing m2 or not, I remembered
after I
sent my first note, it would be a bad idea to sign
a build, and then
declare it without normal "milestone testing".
There are a few cases 
where signing can slow down performance (or, even
"break" function). 
Its unlikely any of those things would hit your code
... but, best 
not to assume too much (to follow my own advice :)

> I'm just starting to get a feeling for the actual
size of the
> community, and the limits of the foundation's
resources.  Eclipse
> succeeds at creating a high profile externally,
and has some
> prominent corporate sponsors, which inflates
expectations to some
> degree.

From one view point, Eclipse resources are tiny, almost
non-existent! 
Unless you include committers like you and us, then
as a group, we're huge. :) 

I'll get you an "S" build job set up ...
that does signing ... 
and with enough notes here to this list, we'll settle
on a process. I suggest you 
may want to consider a M2a build in a couple of weeks,
after testing signed versions. 
You do so few builds, and are pretty small, so if
you 
really want each and every build signed ... we can
do that too. 
The worse performance hit for you, maybe, will be
if you get in the gueue behind
another few hundred bundles waiting to be signed from
a big project ... then it might 
delay things an hour or two ... but, that'd rarely
happen. Probably.  I think 
they usually run three queues. A good load for the
build server as reported by 'top', 
I'm told, is "5 or less". These days, the
machine is often overloaded at 15 or 20 ... 
so, that's one reason why I'm careful. There is more
hardware "on the way" ... I have 
a feeling ... following typical programmer patterns
of filling available space (and time) 
... that it will be just as busy after a few months
of operation. :) 

BTW, a big part of the "signing services"
was done by committers (there is little 
development resource at Eclipse), so if you'd like
to contribute some 
improvements to the scripts, I'm sure it would be
appreciated. 

Welcome to Eclipse! :)

From:	David Carver <d_a_carver@xxxxxxxxx>
To:	Sam Neth <Sam.Neth@xxxxxxxxxxxxx>
Cc:	David M Williams/Raleigh/IBM@IBMUS, WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>, Gabriel Petrovay <gabipetrovay@xxxxxxxxx>
Date:	03/18/2010 10:11 PM
Subject:	Re: Build Signing

---

On 03/18/2010 06:28 PM, Sam Neth wrote:
> While we're looking at the milestone build for suitability, I'm also
> trying to understand the versioning of the plugins; they're all 
> 0.7.0.v*, where * starts with some date that isn't the date of the
> milestone.  Where does that date come from?  Is there any
way for 
> someone to determine what milestone they have by looking at installed
> plugins?

The v* date comes from the date the build was run.   There is no way
that I know of besides checking the date of the map files to determine
the milestone version.  Typically this hasn't been a problem with
eclipse plugins.

>
> I'm learning, but there always seems to be another gotcha.  I
 don't 
> quite understand how jar signing can be so expensive that it has to
be 
> micro-managed like this, but I think I either underestimate the 
> magnitude of the build workload at eclipse, overestimate the size
of 
> the infrastructure it runs on, or both.

Think about it...You have 100+ eclipse projects all going through the 
same centralized signing server.  Thus if every build was signed,
it 
would back up the service, and has in the past.  Projects very in
size 
(small like XQDT) to larget like (WTP as a whole).

Dave