Wrong build order

[anatoly techtonik <techtonik@…>]

When Bitten has missing revisions with build_all turned on, it starts with the greatest number. I expected it to pick the oldest revision first.

[osimons]

No, the most recent revision is the most important build to complete and hence Bitten builds most recent revision first before progressing on older. It makes sense to me, and I would rather see current status of source before I see output from a build perhaps 100 revisions old.

Suggest 'wontfix'.

[anatoly techtonik <techtonik@…>]

Sounds reasonable, but when the most recent revision is built, I'd expect missing revisions to be built starting from the oldest.

[Felix Schwarz <felix.schwarz@…>]

Replying to anatoly techtonik <techtonik@…>:

Sounds reasonable, but when the most recent revision is built, I'd expect missing revisions to be built starting from the oldest.

Well usually what really matters is the latest build as we all agree. To me the importance of a build decays with the age of a build: A newer build might be helpful to find a changeset that introduced a regression but the older the build is the more unlikely it is that we missed a problem that long.

Therefore I'd like to argue that starting from the newest might be the best strategy. However even if it just builds in random order after the latest build, I'd say it's not worth any code to make it a certain strategy given that this seems to be a border case when you introduce bitten.

[anatoly techtonik <techtonik@…>]

Actually a code that allows to choose build_all strategy would be a good thing (tm). I can even see a dropdown box for choosing it near build all checkbox.

[anatoly techtonik <techtonik@…>]

It is also a good extension point.

[hodgestar]

I prefer newer revisions to always be built first. I think most of the time recent history is more important than older history. Seconding 'wontfix' or better yet 'itsafeature'. :)

@anatoly: Do you have a use case were it is generally more useful to have the older build first?

[osimons]

Also remember that neither slave nor master keeps track of any sense of "state" as to what has been built and what is in line to be built next. The slaves requests a build, and the master returns the first in line (if any) - based on most recent revision. Very simple, and makes sense.

I see no good argument for changing the policy - or adding lots of code to maintain something like slave-based build queues that have a sense of "first", "next", "last" - or introduce rules such as "if newer build exist build oldest revision first".

Standing by my wontfix (or variations thereof).

[anatoly techtonik <techtonik@…>]

The use case is a bisect algorithm to find revision that failed first. Quite often projects contain DB migrations that are irreversible and if such migration is executed when a newer revision is built, you won't be able to do older builds anymore.

[Felix Schwarz <felix.schwarz@…>]

I'd like to argue that tests that depend on external resources are brittle by default. If your tests can screw up these resources so you can't run (older/newer) tests, your process is broken anyway(imho).

However maybe you can come up with some code to demonstrate how few extra code is necessary to implement that? Maybe it can be considered for inclusion then?

[anatoly techtonik <techtonik@…>]

Replying to Felix Schwarz <felix.schwarz@…>:

However maybe you can come up with some code to demonstrate how few extra code is necessary to implement that? Maybe it can be considered for inclusion then?

Maybe, but only after 0.6 is released is installed from backports on my Debian machine. Patching codebase that I don't use is susceptible to bugs.