On Sat, 11 Nov 2017, Jed Brown wrote: > >> 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] > > We're confronted with a problem that 'next' has too much failing shit in > it and the solution is to get rid of 'next' because we trust that people > will be more careful when merging to 'master'? I think that's absurd.
Agree - I think the goal is to automate as much as possible - and not rely on manual steps which folks would have to do on their own. > If we introduce a new system (CI, faster local tests, etc.) that > prevents broken shit from getting into 'next', such that 'next' is > always clean, then we could say the overhead is unnecessary. Presumably thats one way to look at a model without next. > > 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. > > No! Bad topology because it makes your branch depend on whatever crap > has happened in 'next', That was in refernce to a 'no-next' model - so there is no way it will depend on 'crap that happened in next'. > thus preventing other branches from getting your > feature without also getting the rest of 'master'. Also makes bisection > harder. If there is a major conflict, you should merge exactly what is > needed. If you just modified a line next to some unrelated modification > (our makefiles are TERRIBLE for this and must be exorcised) then there > is no need to merge 'master' into your branch. Don't disagree here - but this not a justification for keeping the current next model with all the current problems. > > > 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.] > > Huh? Starting from 'master' is the right choice for a new feature. NOT > for a bug fix. But today - you had a branch [origin/jed/variadic-malloc] that started off maint - but was not destined for maint > But when developing a new feature, you don't want > repeated merges from 'master' because it increases the dependencies in > your branch and potentially introduces bugs and behavior changes that > have nothing to do with your feature. You merge or rebase only if you have a merge conflict. If merge is not appropriate rebase can be. The merge conflict has to be resolved at some point. Satish