[wtp-incubator-dev] Re: Build Signing

[David M Williams <david_williams@xxxxxxxxxx>]

I have setup a S-build for XQuery tools,
that signs. 
You'll notice I used a label of M2a
for now. Let me know if/when you'd prefer to move back to an I-build or
use a different label. 
The results, as always, are in 
http://build.eclipse.org/webtools/committers/
After (plenty of) testing, we can move
this build to 'downloads', if you would like. 

While hardly a randomized scientific
sample, the time differences are interesting. The unsigned I-build took
about 20 minutes. I did two S-builds, (used a wrong label the first time).
One of them took 2 1/2 hours, the other about 1 hour. My guess is the extra
40 minutes in the latter case is roughly half "waiting in line",
and half "extra processing" to condition the jars for packing,
and signing. The former 2 and 1/2 hour build shows how sometimes the queue
can be cause quite a bit of waiting, depending on who else is in line before
you. 

> So normally we would have the integration
build signed before 
> promoting?  That makes sense as an alternative to my mental model
of
> how things work.  

Well, no. Not unless you said you wanted
I-builds signed. I just meant 
that builds in the "committers
area" are all for testing, by committers.  
They are not mirrored, and are short
lived. 
Once you get a build you want the general
community to be able to test, 
it is promoted to 'downloads'. I-builds
are still not mirrored, usually promoted  
weekly. These I-builds might not even
be suitable for "end-users" but 
should be good enough that committers
and adopters can continue to build, 
or add function to them, using them
as "development targets".
S-builds, or milestones, once promoted
to 'downloads' are mirrored, and generally 
suitable for end-users that don't mind
the rough edges or incomplete functionality.  


>> 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).
 
> Actually I think he's right; the plugins do all have one date, which
> is the date of the build, because that's the tag I used when 
> triggering the build.  I guess the features don't get tagged.
(?)

Well, if the tagging is done and it triggers the build,
then yes, the tag-time 
and build time will "match" ... but, its still
the tag that is used for the qualifier. 
Hopefully that'll be obvious from the current S-build,
the build date, and tag 
dates will be further apart.

HTH

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

---

On Mar 18, 2010, at 9:08 PM, David M Williams wrote:

 >> 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. 

Acreed.  Just never thought about identifying a build
until I started setting up the update site.

>> 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). 

Actually I think he's right; the plugins do all have one
date, which is the date of the build, because that's the tag I used when
triggering the build.  I guess the features don't get tagged. (?)

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. 

This makes sense.  Good information, and good point.
 

Support dumps are the only way to avoid wasting time.

>> 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. 

Likewise.  I tried to email webmaster and it was
held up too, so I tried again from another account.  Hopefully it
gets resolved tomorrow.

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.

So normally we would have the integration build signed
before promoting?  That makes sense as an alternative to my mental
model of how things work.  

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. 

Another good reason to keep this on the list.  I'll
have to understand things better before trying to write anything authoritative.
 I might take a swing at it if I get there, but I sense it's going
to be a little while.

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 think this echoes the point about promoting a build
that's already being signed. (?)

> 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. 

Sounds ok.  I've come to terms with distributing
an unsigned build for a little while.  

You do so few builds, and are pretty small, so if
you 
really want each and every build signed ... we can do that too. 

Probably not necessary, though not signing every build
does add the admin task of switching back and forth between signed and
unsigned builds, i.e. a little more work for you.  As long as I understand
the process, I think I can live with it.

On the other hand...  In some sense, at this stage
in the life of the project, stable builds are a bit like milestones to
us, and milestones like releases.  I might also set up an integration
builds update site as well, and it wouldn't hurt for those to be signed
too.  I think you'd be fair to assert that's going a little overboard
though.

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. 

I'm sure it does happen.  No way for us to control
that; might serve as an object lesson about why not all builds are signed
though.

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. 

Another thing that will have to wait until I know which
end is up.  :)


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