Thank you, folks, for the feedbacks. I will take them into account. Since a few guys will participate in the contribution, we will add a prefix [scheduler] to the title of PRs and add "scheduler" label. It will let reviewers know they are for a new component and may include some intermediate codes.
Best regards Dominic 2019년 7월 5일 (금) 오후 10:05, Markus Thömmes <markusthoem...@apache.org>님이 작성: > Continuous integration is a crucial aspect of a system used in production > like OpenWhisk. > > As such, let's bite the bullet by merging things incrementally into master. > That will also force you to think about migration on each step you take, > which in the long run will pay off big time. Accumulating a huge change > will never be review- nor mergeable confidently in the end. > > +1 to incremental changes. > > Am Fr., 5. Juli 2019 um 08:54 Uhr schrieb Martin Henke < > martin.he...@web.de > >: > > > Strongly + 1 to put core changes behind feature flags so that they can be > > rolled out (and removed if necessary ) > > in a controlled way. > > Tests should be running successfully for having the feature flag enabled > > or disabled. > > In the near past it took a considerable amount of my time to adapt test > > cases for some of the features > > introduced in the last time to make them work in all cases. > > > > Regards, > > Martin > > > > > > > > > On 5. Jul 2019, at 06:59, Chetan Mehrotra <chetan.mehro...@gmail.com> > > wrote: > > > > > > +1 to commit incrementally to master. > > > > > > If the changes touch the core logic then we can possibly have them > > > backed by feature flags and have them disabled by default and enabled > > > for test case. Further it would be preferable that whatever we commit > > > (at any stage) it should have required test coverage. This would > > > ensures that the sub parts of work in progress bigger feature are > > > backed by unit tests. > > > > > > regards > > > Chetan Mehrotra > > > > > > On Thu, Jul 4, 2019 at 9:35 PM Dominic Kim <style9...@gmail.com> > wrote: > > >> > > >> Hello, whiskers. > > >> > > >> I am trying to contribute this: > > >> https://github.com/apache/incubator-openwhisk/pull/4532 > > >> > > >> At first, I tried to open a base branch and merge all incremental PRs > > into > > >> the branch. > > >> And finally mege the base branch into the master after the > > implementation > > >> is done. > > >> Surely, reviewers would review all the subsequent PRs and it will be > > based > > >> on SPI and disabled by default at first, there would be no big issue I > > >> think. > > >> > > >> And Markus suggested to incrementally merge all PRs into the master > > instead > > >> of having a big base branch. > > >> > > > https://github.com/apache/incubator-openwhisk/pull/4532#issuecomment-508519119 > > >> > > >> With the former, we don't need to include temporal unused codes but > > need to > > >> include a big possibly disruptive PR at once. > > >> With the latter, there will be some temporal unused components in the > > >> master at some point, but we can make sure merged codes do not induce > > any > > >> issue. And actually the latter is easier for me as well : ) > > >> > > >> If we all agree with including the temporal unused codes in the > master, > > I > > >> am happy to work in the way Markus suggested. > > >> > > >> One example of a temporal code is this: > > >> > > > https://github.com/apache/incubator-openwhisk/pull/4532/files#diff-1d7110b32c507a6ef4ac956c287e77ebR24 > > >> > > >> Since there is no other component, the "scheduler" cannot initialize > all > > >> components in the main function and there is only `println("Hello")` > in > > the > > >> initial version of the main function. > > >> > > >> > > >> Please let me know your thoughts. > > >> > > >> Best regards > > >> Dominic > > > > >
