On Sat, 11 Nov 2017, Jed Brown wrote: > Satish Balay <ba...@mcs.anl.gov> writes: > > > 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'. > > 'master'. Same point.
no you are assuming 'master-only' old model. None of my emails refer to that. > > >> 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. > > Your proposed merge strategy (merging from upstream to ensure that an > automated system can merge back) creates the problems described here. > You proposed this merge model as necessary in a no-next model. > > >> > >> > 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 > > I wasn't aware of the mswin const issue when I started it. I was refering to this branch as an example that started off maint (not master) but destined to master. I assumed that was your model of staring new feature branch at oldest possible snapshot - so that it could be merge to maint - in case someone wants that feature in maint. If that was not the case - lets go past this. > > >> 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. > > Having a person do the merge works fine. Sure - hence the author is responsible for resolving potential merge conflicts (as I mentined before). After that - any automated system can take over and so stuff (merges or not) that it deems neecessary for the testing model that we adopt. BTW: right now [with the current next model] authors are not doing the merge conflict resolution. Integrators are doing this. [Sure in our case we are both integrators and authors - so don't see the difference] Satish