On 2/10/19 10:06 AM, Schanzenbach, Martin wrote: > Maybe let me wrap this up for now because I do not see a point in arguing > further and there does not seem to be consensus: > > From a GNUnet app/service developer perspective (i.e. not GNUnet core > services) I have made the experience that the use of proper tooling and > separation benefits the overall experience both for developer and user. > If you are interested in what I mean, you can look at > https://gitlab.com/reclaimid. > > The thing is that the core of this application still resides within the > GNUnet monolith (src/reclaim). > This is a pain for the following reasons: > - No working CI/Testing > - If CI/Testing is working, it takes too f**ng long if I only want to test my > changes / work on this component
Why does your CI runner run unrelated tests? Can't you limit it to only the subsystems you care about? > - I do not need the other sources especially fs and social and they only > bloat the final result (the GNUnet binaries are around 70MB btw) We could introduce a --disable-fs flag (and IIRC social requires --enable-experimental already). > - Development of other things in GNUnet (e.g. transport update, fs) should > not have an immediate effect on my development flow. But they have. Transport: well, that's the integration testing, which IMO is important. > - For deployments, I need a stable GNUnet base (this is why there is a > gnunet-docker in there that builds a lean GNUnet image ~70MB) There the issue I see is more that today we work a bit aggressively on master, instead of doing experiments on branches. But this has partially to do with the CI not being setup to test branches (yet). Still, I don't see why you could not simply work on a reclaim branch that derives from a sufficiently stable GNUnet base -- that is, if your focus is on "stable base" and not "integration with latest development". > As such I will, as proposed, simply try to improve this for _myself_. > If the move to proper infrastructure (which has been opposed) I thought you and ng0 were in the process of doing the Gitlab setup? Admittedly as a trial, but I don't see why you still have a problem here. > and proper separation is not shared, I do not really have a problem with > moving the code I am working on out of the gnunet.git and into the gitlab > repo above. > Since it is, like fs or social, a component that does not have any horizontal > or vertical (upwards) dependencies, this will not affect the status quo in > any way. > Especially since the current "CI" doesn't even build and test most of this > (=reclaim). > > Doing this with social/fs/etc as well would have the benefit of allowing me > to create images which are even smaller and do not contain functionality that > reclaim does not need, but this does not seem to have consensus so I have no > solution for this atm. --disable-FEATURE flats for configure where then src/Makefile.am simply doesn't enter certain subdirectories would certainly have my approval here. Happy hacking! Christian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
