On Sat, 11 Nov 2017, Jed Brown wrote: > > The way I see it - a broken next [where folks can't easily figure out > > who or which commit is responsible for the brakages] - doesn't help > > much.. > > The fundamental problem here is that we aren't accurate enough at > placing blame and getting the appropriate person to fix it. It doesn't > help that we are a distributed team and have plenty of our own > obligations. I can't fix something while I'm teaching class or meeting > with students, for example. But we should all be able to get to it > within a day, either to withdraw the branch from 'next' or to actually > fix it.
Another justifcation for a different model [which Barry wants to pursue] - where one doesn't have to rely one separating out issues from a jumble. And not relying on folks fixing next breakages immediately. > I think a lot of our noise in 'next' is "stupid shit", like compilation > failing on some architecture. Automating a very limited test suite > running on PRs within minutes should help a lot to deal with that. More > subtle interaction problems can and should continue to be dealt with via > 'next'. My claim here is if everyone runs 'make alltests' on alteast one build [whatever their prefered build is] - it will cut down most of the nosie. [yeah this is different noise than what you are refering to] I think Compiler warnings/errors are presumably easy to fix. Broken examples are harder to chase down. [esp when it happens on every build - the logs get unreadable] > > Note: with next - any merge resolution that gets done has to be > > repeated when the branch gets merged to master. [Since git doesn't > > keep trak of this by default] the second merge to master is not always > > the same as the first one in next. This causes merge conflict when > > master gets merged to next [yeah I've seen this a few times] > > If the same person does the merge, the same resolution (assuming it > still works) comes automatically. True - but doesn't happen all the time - and some of us are forgetting how we merged the first time. [yeah - you mentioned some git option to remember - that one can use - but none of us are using it] > The point is that having a bunch of candidate merge branches that > need to be ported around to different machines will be a far bigger > mess than we have now, and still doesn't fix the problems. Not sure what you mean here by 'bunch of candidate merge branches that need to be ported around' If you need to resolve a merge - you merge 'master' to your feature branch and resolve it [or rebase it]. The resolution is in your feature branch. Sure this breaks your current workflow of staring with oldest possible version of petsc for any new feature [not latest master]. But none of us are using that model - and the burdens of that model are not worth it [as we are not really using the benefits of it - like some of the other projects that are using this model.] Satish