I have some inline comments as well below, but let us bring this discussion down to a more practical consensus maybe. I think we are arguing too much in the extremes and that is not helpful. I am not saying we should compartmentalise GNUnet into the tiniest possible components. It's just that I think it is becoming a bit bloated.
That being said, _most_ of what is in GNUnet today is perfectly fine in a single repo and package. For now, at least let us not add another one (gtk) as well? Then, we remain with - reclaim (+the things reclaim needs wrt libraries) - conversation (+X) - secureshare (+X) - fs (+X) as components/services on my personal "list". I suggest that _if_ I find the time, I could extract reclaim into a separate repo as soon as we have a CI and I can test how it works and we can learn from the experience. Then, we can discuss if we want to do the same with other components, one at a time, if there is consensus and a person that would be willing to take ownership (I am pretty sure we talked about this concept last summer as well). > On 9. Feb 2019, at 13:38, Christian Grothoff <groth...@gnunet.org> wrote: > > Signed PGP part > On 2/9/19 1:06 PM, Hartmut Goebel wrote: >> Assume we have a huge repo: >> >> * The total number of build-triggers is the same as for a smaller >> repos (assuming each push is a trigger). >> * The build-time of each repo (much) longer, since the whole repo will >> be build from scratch. Since there are no files from a last build, >> everything has to be build. > > Is that true? autotools can re-build based on timestamps that have > changed for like forever. With Buildbot, I can certainly do incremental > builds, I am not forced to do a "make distclean" every time. Similarly, > build triggers do not have to be as coarse as "any push", I could > specify a push to directory X triggers tests (make check) in directories > X, Y and Z, or not? > > If the CI requires always building every repo from scratch and always > running all tests, maybe the CI is to blame? IIRC with Buildbot, you do > have more control than "always redo everything". The tests and build should not be stateful. I do not see any advantage in having stateful builds _especially_ in C-based and autotools-based projects are existing linker artifacts may obfuscate FTBFS situations on clean environments. This has happened to me before and is one of the reasons I keep bitching about CI (and with that I mean: automatic build and test in clean environments). > >> * Developers get the CI results later sitting around waiting for the >> result. (One of my projects takes 1:30 to finish CI, which is nerving.) > > Agreed, but faster tests, parallel tests and selective tests based on > dependencies (which can theoretically even be decided automatically) > seem to me like the smarter solution here. > >> * When packaging (.deb,.rpm, guix), huge repos/archives are much more >> nerving to package: Build-time is long, test-time is long, and if >> anything fails or new patches are required, you'll start again. >> (Some of the KDE packages take 15 Minutes to build. Iterating this >> really woes!) > > I'm not convinced that one big build is really much worse here than 50 > small ones. Then you need to refute how you justify building a libgnunetutil and dht and testing again because you updated the gtk UI (hypothetically, if it were in the repo). > >> (When configuring gitlab-CI some of the issues could be solved, see >> >> https://docs.gitlab.com/ce/ci/yaml/README.html#onlychanges-and-exceptchanges) >> >> Also from a developers perspective, a huge repo has some drawbacks: E.g. >> when switching branches or bi-secting, git will touch a lot of files >> which all need to be rebuild, which is taking time. > > Granted, but your Git-driven bisection totally becomes much less useful > if you first have to identify which of the 50 repos really is the cause > of the regression. So here you are trading touching files for the power > to more easily identify non-obvious sources of bugs. No, because even if your repo is triggered to build+test because of a change in the code of another repo, then you wouldn't even start bisecting. Actually, you can't because your git repo didn't see any commits! You simply have a failed test instead of X commits which have nothing to do with your codebase but you now may have to disect (which then again is pointless but you do not know that in advance). > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
