On Sun, Nov 22, 2020 at 12:01 PM Waldek Hebisch <[email protected]> wrote: > > On Sun, Nov 22, 2020 at 09:15:36AM +0000, Dima Pasechnik wrote: > > On Sat, Nov 21, 2020 at 3:32 PM Waldek Hebisch <[email protected]> > > wrote: > > > > > > On Sat, Nov 21, 2020 at 10:56:17PM +0800, Qian Yun wrote: > > > > We have a discussion about Travis CI 3 years ago, now we have > > > > moved to GitHub, I believe now it's time to have CI? > > > > > > > > One point Waldek raised was "run test before commit". > > > > > > > > If we have CI support, and you commit in your own master repo > > > > before merge into main repo, you can "run test before commit". > > > > > > > > For pull request, with CI we can run tests before commit. > > > > > > > > Even if we commit directly into repo, with CI we can find > > > > problems more quickly. > > > > > > > > (Anyway, I assume we don't run a full build and full test > > > > before commit, most of time, right? :-) > > > > > > I do run full build and full testsuite before almost every > > > commit. > > > > Do you say that you expect every contribution to be wrapped up in > > exactly one commit? > > (This is not very usual, although there are workflows where this is a > > requirement, e.g. > > https://en.wikipedia.org/wiki/Gerrit_(software) - used at Google, AFAIK is > > built > > around such a model) > > > > No. I expect commits to be reasonable self-contained and > logically connected units of work. If somebody wants > to contribute two unrelated domains, then it is natural > to do this as two commits.
This gets very messy as soon as contributions are no longer individual, as merging joint work in a single commit is tricky, error-prone, and removes authorship from all but one contributor. That's why feature branches and PRs (these are the same on the level of git, GitHub's PRs are just feature branches) are a much more common kind of a workflow. > OTOH cluster of cooperating > domains and categories + changes needed to connect them > to rest of algebra naturaly fit in one commit. Bug > fixes naturally go as one fix per commit. And when > somebody fixes unrelated bug developing something else > (say output problem when working on computational > problem) then bug fix naturally comes as separate commit. > > > > I sometime make exception when change is obvious > > > and and does not change code and I am goind to do another > > > commit with full build and full testsuite run just after > > > current commit. I expect other people to do the same > > > (those rules appeared here several times and should be > > > well known). This may look extreme but: > > > - project that use more relaxed rules freqently have > > > non-buildable repository and this would be bad > > > - IME before commit test from time to time catches problems > > > (fails). Catching/correcting them later would cause > > > more trouble. > > > > In danger to state the obvious (to me): > > the idea of CI is that *you* only look at a contribution after it > > passes pre-defined > > automatic tests, and these are as extensive (and possibly much more > > extensive, as it can be > > done on many different platforms (i.e. OS+LISP) at the same time) as > > *you* would do by hand. > > It is meant to save *you* time. > > And avoid SNAFUs such as "oops, it's already merged, but it does not > > work on FooOS with BarCL". > > You previously wrote that CI can cover several platforms, that > is true. And for some folks CI may be more convenient than > local testing. I am just saying that for me build machine > takes something like 2 min 30s real time for full build > (parallel) and testing about 3 min real time. When platform > dependent code is involved, then I run more tests, but that > is rare (vast majority of FriCAS code is platform independent). While it's probably not often that one gets code in Spad (i.e. as platform-independent as it can be) that runs on one platform and fails on another, it looks not at all impossible. > > > > > > > > So, if we all agree to add CI support, I'll post a simple > > > > CI script for discussion, and we can add functionality > > > > gradually over time. > > > > > > Well, more testing is better than less. Just I do not > > > consider CI as game changer. > > -- > Waldek Hebisch > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20201122120132.GA22235%40math.uni.wroc.pl. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq0T4CdPcx-F1tB%2BxkgkizppL%3DRJx9JWCrb88G4yHALRaA%40mail.gmail.com.
