On Wed, 2017-09-27 at 17:32 +0200, Michael Moll wrote: > > > This would be PR-blocking, I assume? I'm fine with that, just > > checking. > > While I'm +1 about this in general, the two specific cases for > Discovery > the last weeks were Rails 4.2 -> 5.0 and separation of puppet facts > from core. I can't see how a merge block on plugin breakages can be > mandatory. Of course it's nice to know that a change is breaking > plugins, and ideally the core PR author provides PRs to the affected > plugins then, but I worry about further reduction of core > development/merge speed, which is already not at its best...
Hmm, good point. There will always be a mix of cases where core is at fault, or where it's just a necessary update-and-roll-forward. I think there's two views here, we could go either way: 1) This is advisory-only (non-blocking), but has the advantage of making more people aware of potential plugin breakage in PRs (compared to only the authors really finding out in a few days when the standalone plugin tests get run) or 2) This is blocking, but the processes that were discussed a few weeks back, about when to merge things with red tests, needs updating to account for this new test matrix. > > * Bandwidth takes about 1/3rd of our $2k budget - perhaps we can > > affect that > > Can we somehow see which part is taking most? I.e. is it the CI part > or rather the website? I'll see what I can do. The Rackspace billing does provide an extensive CSV of all charges (several MB, which for CSV is impressive :P), so I may well be able to pull something from that. Greg -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
