Hi Luca and Jesse, Changing subject to "associate the broken build with one of the members (or even teams)" because I feel that's crux of the technical development workflow problem, and scenario, that Luca wanted to discuss.
In my experience, the easiest -- and simplest -- way to associate broken build with one of the team members, is to formalize ownership and delegations ... akin to package maintainers found in major Linux open source distributions (e.g. https://wiki.debian.org/DebianMaintainer ). Since earlier discussion touched briefly on non-open source use cases, here's one bug / broken build with a latent bug surfacing that really belonged to Facebook Networking software development team... instead of the Facebook iOS Application software development team who triaged: Facebook Engineering blog: Debugging file corruption on iOS ( https://code.facebook.com/posts/313033472212144/debugging-file-corruption-on-ios/ ) In scenarios like the above case of a latent bug, git-bisect would not have worked right away, nor would a plugin such as non-open source validated merge ... to associate the broken build with one of the team members (or even teams). Fixing the latent bug took actual human beings triaging, plus many crash reports during each iteration... I feel once we collectively gain experience with projects and/or systems with enough complexity of: * Latent bugs surfacing during Continuous Integration timeframe * Concurrency, Race conditions, Parallelism, Distributed nodes, Quality Assurance * Vertically deep software stacks, Horizontally across Networks, Computers, Organizations, Teams, People, and Subject Matter Experts ... 1. Iterating through star-shaped graph-shaped topology (where every new commit introduces permutation and complexity) where dedicated builds will cost everyone more time, and probably money too... 2. Thus time-bounding a batch of commits to a baseline (e.g. checking tip of a ref) is one approach, and having package maintainer, accept or reject a batch of commits, then git-bisect as needed... 3. Or in cases of latent bugs surfacing during continuous integration / build timeframe ... A single git commit might be the trigger, and not the root cause at all, of a latent bug in an already-accepted commit from weeks or months ago... Cheers, Lloyd On Tuesday, January 7, 2014 2:56:32 PM UTC-8, Jesse Glick wrote: > > On Tue, Jan 7, 2014 at 5:25 PM, lucamilanesio <[email protected] > <javascript:>> wrote: > > there could be more than one push in between the Git plugins polling > intervals. > > Validated merge does not rely on scheduled polling. Each push > immediately triggers a dedicated build. > > Again this should probably be taken to another forum since the plugin > is not open source. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
