On Sat, 11 Nov 2017, Jed Brown wrote: > Satish Balay <ba...@mcs.anl.gov> writes: > > > On Sat, 11 Nov 2017, Jed Brown wrote: > > > >> > I don't think we have the resources to run full tests on every branch one > >> > at a time. Do we? > >> > >> No, > > > > Well the hope is - after the migration to new test suite is complete > > the cost of a full test run is lower. And we could somehow do fewer > > tests to capture most issues. > > > >> and after each merge of a branch to 'master', the prospective merge > >> of other branches would need to be retested. But the idea that the > >> automated test suite is infallible is also flawed. > > > > Well arn't we relying on 'automated testing' with the current next > > model? > > Some of us also run 'next' in daily work and fix issues as they appear > in that context. There is also significant convenience in there being > one place we can go to reproduce all issues.
If you need next for some other purpose than graduation branches to master - than you can crate a workflow [with next or a different branch] for that purpose. 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 other option I've been comtemplating [wrt next-tmp] is - test all feature branches for barry one day - and all from matt - the next day etc. Then I don't have to figure out which commit broke things. It would be one of the branches of that author - so they can deal with figureing out what broke. [and then throw this away - and test some of the branches the next day] > When testing separate branches, it isn't enough to merely test their > head, we would have to test the result of a candidate merge. Yes - thats what I've been saying - test 'master + feature-1' > If there > are any conflicts, that merge needs to be done manually, but where would > we put it for automated testing? If there are conflicts - there wont' be a merge or a test until the author resolves the conflict. [via a merge or rebase]. This can go on until the feature branch gets merged to master [or maint] > Make a new branch 'candidate-merge-jed/foo-to-master' and push > that, then look for results several hours or a day later? With > 'next', we make merges to one place and don't need a different > workflow for no-conflict versus conflicted merges. Yes there has to be some mechanism to say the branch 'candidate-merge-jed/foo-to-master' is ready for master. Most folks appear to use PRs for this workflow. But we don't. And Barry doesn't like it. So instead of PR - branches can be placed in some placeholder. For ex: I'm currently getting branch list from 'next' - selecting a few of them for next-tmp tests. Wrt merge conflicts - an author is primarily responsible to resolve them wrt master. If master changes with new feature - which causes conflict - another merge conflict resolution is required - it should be the same amount of work as doing this with next. 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] Satish