When the dev updates the default branch I expect to be able to pull it and have it build without failing. My staging branches will never be 100% stable for every feature merge. When it's stable and features are merged, then the default branch is updated. Many times a project's features or fixes take a really long time to get tagged, so pulling the latest tag can be months old, while pulling the latest default may have fixes, so it should compile, period.
Discussion
that's the conflict, between the "main is the release" and "main is the unstable development" because it's the most visible, if you only allow stable releases on it, the activity you see on the main page of the repo is very slow and seems like nothing is happening
building in public is a key part of the social engagement of open source development and for that reason, the consensus is moving towards unstable mains, and forget main, call it "dev" or "development" so it's clearly unstable, and mark milestones on tags, which can be combined with "releases" when a minor or major version bump happens, build out binaries or whatever as the case may be, package APKs etc
the main branch SHOULD always build though, when i say development i don't mean unstable as in can be not working but unstable as in, may have bugs still until those are fixed and put into a tagged release with a version number
for reasons of how the Go toolchain looks for the newest release or newest tag, it's also important for developers with libraries because the tags are easy to remember and you can write them straight into the module file (like a package.lock, but sorta like a package.json but it's neither)... anyway, the same thing can be applied, not so automatically, with other languages, but yeah
i agree that it should build on the main branch, i just don't agree that it should necessarily be working, and that this is what tagging is for
side branches make sense only with a very large project and teams of more than about 4-5 developers, and the first level of them usually will be platform targets more so than features... again it depends on the size of the team, two guys on a project mostly you can just work on a branch that's your branch and then merge them up to the development branch when they are building and kinda runing, and when the features are stable, you tag a minor version bump, otherwise, tagging patches for potentially unstable changes, so they can be easily referred to
Are you assuming that they needed 400 commits over 3 months, to come to an increment that would build? They could have been pushing to main the whole time, regularly.
This was a tactical decision. They know that everyone waits for main, to start reviewing, because we assume things in dev branches are still too much of a construction site, to make it worthwhile to dig through someone else's code base.
The increment is also just way. too. big. Ain't nobody got time to read all a that. Straight to blind install.
Not defending primal here. Defending building things in dev, and testing them before committing to master to keep master stable.
but actually the question is, which branch should be the one people see as "default" dev, or master?
one looks like slow motion, the other is active, all changes that are working but maybe unstable go there (they compile, ofc)
who is more important in open source? the devs who might contribute or audit or test, or the public?
the public doesn't matter, they go to the landing page not the repo
Yup, the active one :Check:
I don't know, but I've been trying to review other people's stuff, and submit issues, and it's just too much bother, in this case. Like trying to interact with a brick wall. They just ignore me, every time, and now this.
They're looking for adoration, not collaboration, so I'm not the droids they're looking for.
yeah, i had that with LND and BTCD too
https://realy.lol won't be mean to you tho, i promise
help with documentation and document comments and asking pointy questions about "wtf is this shit bro" will definitely most warmly welcomed
🫡
Do you mind if nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn and nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 also take a peek? They're really good reviewers.
if nobody hears a realy fall in the woods, did it happen?
I'll start code reviewing tomorrow morning. What's the best place to leave comments or questions?
^ I'm building a container wrapper as we speak!
one of the most beautiful things about Go is you can actually not use containers, but ok
It's useful for isolation. I don't need to keep the build tools on the server. My servers a really stripped down (don't even have git installed) I use podman and compose to build and deploy services repeatably.
well, static binaries, no dependency hell, i got into using it because of C++ and python messing up my VPS and home pc systems dozens of times trying to run especially serves
remote code execution vulnerabilities are zero unless the server actually has a programming language built into it, the GC zeroes all memory before using it and it's not difficult to maek sure important stuff is zeroed before releasing it, and there is code fences though i haven't looked at them in a while... i will be soon though maybe to keep the relay identity from being accessible to other processes in the execution environment
and i basically run the relay from source code compiled on the relay... 1gb of memory, taeks about 10 seconds at most
Also Go makes me ill and I don't want it touching my systems. It might infect me XD
