We only use this value for a few builds and the setting is usually about 5 minutes. Once Mercurial support is there, intend to use much higher values (hour or more) for a few performance test builds.

com.atlassian.bamboo.v2.trigger.DefaultChangeDetectionManager already supports QuietPeriodAwareRepository. We just need to get Git & Mercurial repositories to support this interface and it should work.

Chai, I need your advice. Would we like to have 'quiet periods' implemented per repository separately, or would we like to move the logic into AbstractRepository (and thus supporting 'quiet period' in all Repositories at once) ?

What do you think?

We allow users to configure this.

Yup. I'm just curious what values are really used (usually) in production.

I can hardly imagine a situation where 2 developers would be coordinating their commits by using the same DVCS repository as the CI uses. Do we agree (or disagree) on this, or would you like hear the details of my opinion?

I agree that it is not very likely to happen if people use DVCS in a true DVCS spirit.

The other case, where a developer forgets something and then follows up with another commit soon after still holds true though.

Yup, this might happen, even in DVCS

Looks like we agree

what 'quiet periods' do you usually use?

We allow users to configure this. It could easily be something like 10 minutes for someone to realise that they forgot something, fix it and commit it.

For a build that takes hours to run, for example, a very thorough functional test run, it may be worth it to wait.

"This allows for a bunch of commits to be done before build is kicked of. For instance, 2 or more developers coordinating their commits. Also covers the case when a single developer "forgets" submitting something and needs to correct it quickly."

For instance, 2 or more developers coordinating their commits.

I can hardly imagine a situation where 2 developers would be coordinating their commits by using the same DVCS repository as the CI uses. Do we agree (or disagree) on this, or would you like hear the details of my opinion?

Also covers the case when a single developer "forgets" submitting something and needs to correct it quickly.

Yup, this might happen, even in DVCS. Bob - what 'quiet periods' do you usually use? I'm just curious if these are more like 1 minute periods, or more like 60minute periods (or more)?

Hi Bob,

Thanks for the clarification. I agree, we should be consistent across VCSs.

Piotr, would love to hear your thoughts on why you thought DVCs make this feature less useful.

Cheers,
Anton

Anton, yes I was being a bit short . I think the features needs to be VCS independent. The reasons given in BAM-1178 are VCS independent. I was surprised new VCS's added did not have the features. Also, remember, builds aren't just compiling a bit a code, but can be builds, test runs, or other processing that takes hours to run and uses significant resources. It is needed for some of those cases. For normal cases, I wouldn't use it either.

I think Piotr was more after why this feature would be used, and why it is useful.

Piotr, why do you believe that with DVCs this feature would be less useful?

We already have this feature for other VCSs that Bamboo supports. The feature allows to minimize the number of builds that are done, as it allows for more time to collect more changes into a single build.

In environments where builds mostly pass, or where it is very easy to trace a failure to a particular change, I can see how this feature could be useful.

Personally, in the environments I worked with I would prefer not to use it as I would prefer each build to have the minimum amount of changes.

However, I can see how in certain environments the feature would be useful.

As I asked above, Piotr, could you explain why you believe DVCSs make this feature less useful?

Cheers,
Anton

I would use it if it were supported . Why would I write up the item if I didn't want to use it? DVCS or not has nothing to do with it.