That's pretty much what I ended up doing. Install Gnu Make 4.4 as part of the pipeline. I then added a check to warn the user if the Make version they use is not supported.
Nowhere as convenient as using psql but you could try using Python or Perl to have a more civilised interaction w/ SQLite. For Python the module sqlite3 is already in the stdlib and for Perl just install perl-DBD-sqlite using your package manager.
I'm a software engineer by profession and passion and have been writing programs for well over 20 years now. I believe your experience is totally natural - at least I share the same feelings:
Large code bases take time getting to know and understand: most definitely true. It takes time and effort and is an investment you need to make before being able to feel confident. You don't need to fully comprehend every aspect of the project before you can contribute but you sure need to have a decent enough idea of how to build, test, run and deploy a particular feature. See point (2).
Don't let the size of the project intimidate you. Start small and expand your knowledge base as you go. Usually one good starting point is simply building the project, running tests and deploying it (if applicable.) Then try to take on simple tasks (eg from the project's issue tracker) and deliver on those (even things like fixing the installation docs, typos, ...) That'll have the additional impact of making you feel good about the work that you're doing and what you're learning. I'm sure at this stage you will "know" when you're confident enough to work on tasks which are a bit bigger.
During (1) and (2), please please do NOT be tempted to just blindly copy-paste stuff at the first sign of trouble. Instead invest some time and try to understand things, what is failing and why it is so. Once you do, it's totally fine to copy-paste.
After all, there's no clear cut formula. Each project is a living and breathing creature and "not one of them is like another." The only general guideline is patience, curiosity and incremental work.
That's usually true except that this project is about the Makefile itself 😁 I'm working on a set of useful recipes, targets and variables which I've always missed from Make's out-of-the-box offering - something like a stdlib/utils for Make.
And yes, as you may have already guessed, I've had to deal w/ Makefiles relatively frequently 😀
RE Travis: I feel quite comfortable and happy w/ Travis already. Additionally, I want to keep my reliance on github minimal. The only reason I'm using it is that it is where things are searched for and found by fellow programmers :-)
RE Container: My home machine is running Tumbleweed which's had Gnu Make 4.4 for a few months now already. I was trying to make the pipeline behave as closely as possible to the user's machine who may not have that version installed. Otherwise as you and @sugar_in_your_tea@sh.itjust.works mentioned, I could pack everything I'd need in a container.
Not a direct answer I'm afraid but I use Tree Style Tabs. You can group tabs (in a subtree), move them to other windows (drag and drop), close them together, ...
It's helped me a lot keep my browser tabs tidy and grouped up by relevance.
I don't think you'll be able to achieve that with systemd paths, I'm afraid. It's not a use-case it is designed for.
It's hard to come up with a suggestion without knowing more about the depth of the directory and the number of nodes in each level. But you could try updating a dummy file such as latest_timestamp in the top-level directory (which a systemd path can monitor BTW) and let the service unit be triggered by that.
I had no idea you could do that via about:config 😅 I would always either disable "Use the selected profile ..." or launch it with firefox -P --no-remote as suggested.
FYI after years of having several profiles for different activities, I settled down on Multi-account containers and have been quite happy with it. I even wrote a little blogpost about my experience sometime ago - you might find it useful.
I wouldn't say so. I'd say you can try quickly skimming through the theoretical explanation and instead reading the code snippets provided. I've got a feeling that you're already familiar with the concept and can figure out the code - it's just the math behind it which can read too intense.
I'm not using it myself as am on Tumbelweed but I do know it's quite similar to the idea OP is talking about. Oh and I couldn't find any references to it being beta on the website 🤷♂️
I see your point. Though the main thing, as I mentioned in the question, is that I'm using features from 4.4 so that strategy wouldn't work for me.