continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wendy Smoak <>
Subject Re: Schedules and Build Queues
Date Sat, 20 Jun 2009 01:34:12 GMT
So... I've thought about this, tried to explain it in presentations
about Continuum, and talked to users about it.

The most devastating comment I heard was from someone who has tried
Continuum on and off since the early days who said, "You've added a
lot of complexity."

IMO, the additional control is not worth the added complexity.

It would be different if we'd implemented the simple case first and
had people complaining that they need to do X.  But so far, I haven't
met anyone who understands how this works.  (I'm not exactly clear
what happens with the queues you *don't* attach to a schedule.  And if
queues are attached to schedules, then what about forced builds?)

I think we should remove the 'number of builds allowed in parallel'
from the general configuration screen, and just have some queues.
More queues, more builds can happen in parallel.

Let's see what people think here, then I may float the idea in the
user list to get feedback.


On Tue, Apr 28, 2009 at 9:05 PM, Deng Ching<> wrote:
> Hi Wendy,
> (Sorry for the very late reply :)
> The Build Queues were attached to a Schedule so as to give some control over
> where or in which build queues projects are/can be built.
> Users can also control the number of build queues running for every fired
> schedule. If the schedule and build queues were totally separate, users
> won't have
> this form of control..
> Thanks,
> Deng
> On Tue, Apr 28, 2009 at 9:51 PM, Wendy Smoak <> wrote:
>> ping?
>> On Fri, Mar 13, 2009 at 6:58 PM, Wendy Smoak <> wrote:
>> > I was wondering... what was the motivation for attaching Build Queues
>> > to a Schedule?
>> >
>> > It seems like it would have been simpler to have these as separate
>> > things.  There are schedules, builds happen, and there are some queues
>> > to use.  What do we gain by connecting them that we wouldn't have
>> > otherwise?
>> >
>> > (I've invented a possible use for it, but I can't quite get all the
>> > way through the use case with the current implementation.)
>> >
>> > Thanks,
>> > --
>> > Wendy
>> >

View raw message