this is just an observation.
when i see a project go silent on the public repos, and then cut a major release from a closed repo.
i start to consider their code as open in name only, or vaporsource.
it is a code/release pathway that only becomes harder to work with over time as the mainline diverges so much from the sprinkling of source that we get to see.
All of our code is released on public repos. Please provide examples of where our code is not visible and we will fix this issue immediately. We believe in remaining open sourced.
https://github.com/PrimalHQ/primal-server
and https://github.com/PrimalHQ/primal-caching-service
is main branch what you run in production?
having a main branch and tags for all repos is what i'd like to see
Wow, color me shocked. 🤣
its all open, the development is just happened in the dev branch (accessible from anyone on guthub)
I was wondering where this came from. Nothing since Aug 29 and then a gazillion commits from 1 hour ago.
guys, are you understand the concept of branches? It has been all public in dev branches, I lurked commits real time during last months
https://github.com/PrimalHQ/primal-caching-service/tree/dev
this dev branch is 100+ commits behind main
ponymontana literally posted just a few days back about how he'd been spying out some big movements on some repo, i guess maybe it was primal?
yes, at least android was all open in dev branch, every commit has popped in real time in the past months
caching service is not supposed to be delivered as binary and its possible it has not been uptated at all. The source for all platforms where they release binaries have been updated real time. I'm at least 100% sure of android as I followed development directly for last months
guys, are you understand that you shouldn't be working on a branch for months without committing to master?
490 commits without a merge to master. 🥴
The 90s called and they want their waterfall model back.
yeah, partially agree..
you can waterfall all you want, major releases need tags or it didnt happen 🌊🌊🌊
love the waterfall ref tho for real haha 😂
brings back some memories 🌊 of the pre-git era
I'm from that era. 😂 I was hoping it is now very dead.
Yo, continuous delivery is what I'm used to now. Even waiting a couple of weeks for bug-fixes is nerve-wracking, but they've left me hanging for 3 months.
And we fork from master, not from all branches.
I'm still hanging, by the way. 😏
I'm apparently supposed to search through this alphabet soup, to keep up with development, even though they haven't even responded to the issues I've submitted.
7 months diff between dev and main. Okay. Whatever.
I don't like a master that isn't completely stable though. Lots of big projects without a stable master. For me, master always builds and produces a ci/dev release until tagged. Develop branch is for staging.
If you're a team developing full-time on a project, you should be releasing a stable increment every couple of weeks, at the latest. Gigantic merges are impossible for humans to review, and it means we have to beta test the entire thing, at once.
The users just mass-downloaded this, even though it's been off in a dev branch for months and is a major release (even if it's missing some of the changes I expected, like improved login).
I mean, everyone just trusted them and downloaded this monster. The whole point of open-source is that you don't need trust because the development is conducted in a maximally-transparent manner, with frequent releases facing scrutiny by the end users.
sometimes i wake up and decide to run some opensource. i would have run a primal, but i didnt even get to the clone.. because i realized, the code is gone.
agree with you and there is absolutely great value on releasing all backends (and shame for who keep it close). Still the drama about "users trust" is nonsense.
No, it's not. That team has a big trust deficit, with those of us who have been here, for longer, as they keep doing weird stuff. Finding out that they ignored the issues and the PRs for the web-app, for 7 months, while fiddling around on a different branch, while everyone continued to fork from main, is like wut.
Dev is 585 commits ahead. The last tag is from Aug 31, 2023. This is just weird behavior, for a Nostr project. They're publishing, technically, but doing it low-key and avoiding the social interaction that is typical of FOSS.
nah, there are different ways to approach foss and different sizes and scopes for project. Primal is evidently a more "company-driven" project, and its okay, it has his role in the space. In the end they implemented nips and tend to be compatible with protocol releasing source code for every binary they ship.
Also the product is solid, more than most of the community-driven projects can be, due to more resources invested.
I also prefer to use and contribute to more community driven projects, and I think that they tend to respect more users and become better with time, even if initially they tend to be more buggy and unpolished.
But every software has his space, and primal team is definitively a good actor, delivering a fully foss client on multiple platform.
And no seriuos dev has forked and worked on main branch without realizing that the company was working on other branches, it require just a minimun literacy and competence to figure out.
Okay, thanks for confirming that the Primal devs aren't interested in working with illiterate, incompetent, unserious people like me, so they're just off doing their own corporate thing. I think I've figured that out, now.
come on, stop this drama, its risicolous.
i don't work with nonserious people either, i don't think that's you actually
I'm as nonserious as a funeral, seeing as how I test safety-critical and sensitive-data software, for a living. That's precisely why I don't like it when people just do weird shit to established processes, without even publicizing and defining WHY they are doing it, or how we should best deal with their fork of the process, going forward, or giving us a chance to join in the fork.
They just went and did their own thing. Okay. Just reminds me why I'm sticking to the other kind 01 clients.
personally i find primal's color scheme jarring and uggly, like, literally they follow the scheme of colour for the game Kingdom for the bad guys (greedies)
this is false, they are modern and auditable codebases, and the commits well organized and self-explicable.
All is open, accessible and understandable for everyone.
The point is that they follow a not so common dev practicing that could let new people on codebase a bit disoriented, but it doesnt impact the possibility of read the code and audit it by any means.
Every codebase is different as it could fulfill different porpouses, so this drama is totally nonsense.
i am interested in their backend, when i asked, they didnt have an answer. will they only open the client code and keep server private? imquiring minds.. want to know..
frankly dont know about backends codebases. Its super important to open source all and would be great to have responses about that.
Still, backend involves trust in who runs it and offer the services, opening the source doesnt make much difference in reducing the trust that users need to put as theres no way to audit the computation happening in the backed.
opening the backend source, means we can keep primal honest by running our own.. if we cant, thats not very nostr like. if clients all use a primal cache cause its so cool and fast and has all these features, but its closed source, then we didnt accomplish the mission to decentralize.
maybe the 3 months of no commits just means there arent any new commits because backend is the same as 1.0. i would highly doubt it. which is why i asked.
agree with you
IMO, the main/master/dev branch should always be the default one, and fixes and features should be marked by tags, that's how i do it
but some think of the master/main as some kind of precious that you only update every few months
not putting the main work on the default branch makes a repo look ded, and it's stupid doing that, branches are not where you make releases, you have tags for releases ffs lol
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.
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
