On Sun, Nov 22, 2020 at 8:07 PM Waldek Hebisch <[email protected]> wrote: > > On Sun, Nov 22, 2020 at 04:47:38PM +0000, Dima Pasechnik wrote: > > 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. > > Authorship does not depend on version control. If you mean that > automatic commit information is no longer correct, we have > ChangeLog which allows specifying authorship without artifical > limits of version control.
Times of ChangeLogs are gone. Nowadays people would rather look at https://github.com/fricas/fricas/graphs/contributors and not at the ChangeLog. > I would say that in case something > is a single unit of work splitting it makes things messy. splitting is messy, but working on something as a group is quite normal. And then exchange of updates is done via commits, so the end result is a branch with many commits from different people. Yes, it can be squashed, but often it's not desirable. > > > > > 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. > > Well, some work fits naturaly into branches, but AFAICS most > cases relevant to FriCAS just commiting when ready is the > best way. > > > > 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. > > Impossible -- probably not. But past practice is that after > initial port Spad code just works. There were bunch of > cases with bugs in Lisp compilers. When we learn about bug > of course we report it. But actively searching for bugs > in Lisp compilers is not main point of FriCAS. > > -- > 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/20201122200653.GA29525%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/CAAWYfq3nTEfxV4uCbFp-K62h79Wzm-2ERkBhkdGBsGgCJO63eA%40mail.gmail.com.
