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. I would say that in case something
is a single unit of work splitting it makes things messy.
>
> 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.
