That's the easiest way to do it. A file gets dropped in
specific
location (BUILD-SUCCESS, BUILD-FAIL) that can just be watched for. We
don't have to have instantaneous knowledge of build success.
Right now it's just if the package name/v-r dir shows up in the right
'stages' dir.
See:
http://extras64.linux.duke.edu/needsign/development for examples.
It just sounds like query is mostly needed. And for the nice, easy
to
use build target from the makefile, open bug/add comments. Those should
both be present.
<nod> I've not heard the latest status on the package tracking interface
in bugzilla. Does it sound like it is near or far? Near == 2 weeks, Far
== 2 months.
> 2. Users cannot directly kick off builds, they have to wait
(waaaaaaah)
So long as the polling is done frequently enough, this isn't a huge
deal.
right now it's every 5 minutes.
> 4. Ordering of builds based on dependency
FIFO. You need to request your builds in dep order. Sucks a little,
but is easy to implement :)
agreed.
Also, another thing I've thought about (and it's run through my head a
few times, this is just the first time I've remembered to type it out).
One thing that would be nice would be able to have multiple roots for
the same release in mach easily (ie, without having to make copies of
the config files with tweaked paths :-). At the same time, that's
probably not something that matters in the short term as it could easily
be added as an optimization later.
I thought about that some. We'd need something that tracks what root it
is in and make sure to request that same one again. For mach we'd need
to open it up to the possibility that the root name is not the root
location. I'm not sure how hard/easy that will be w/o looking more
closely.
-sv