i think nginx has an oauth_module which would allow you to use something like keycloak, if you want more than basic auth.
for apache mod_auth_openidc exists.
setting up an oauth-provider is not exactly trivial, but well documented and could be worth it if your other services offer oauth2-support or don’t feature a login at all.
for many people homelabbing is a way to gain knowledge they can use on the job.
other than that: proper single sign on across your services is nice even if you don’t expose them to anybody else.
yes, but what are “grooming gangs”?
It seems like something we allready do at work, with feature-branches that collect multiple prs that are required for a feature, but with some proprietary bits and bops instead of an internal procedure and standard git features.
i guess it’s nice for people who use github in their team, but it furthers lock-in.
Antarctica doesn’t really count.
There is nothing in the rules stating that a Pinguin can’t be Captain of a Starfleet vessel!
Je Duits is zeker beter dan mijn Nederlands
https://cgit.git.savannah.gnu.org/cgit/parallel.git
current release is “rape gang inquiry”.
i don’t know how or why releases get named by the project and have no idea about the blog chain stuff.
why do you want this?
and does the build need to happen elswhere? otherwise you could read the target directory from the build file and move the stuff afterwards.
Sure, maybe 2 minutes. But not only does each 2 minute interruption actually cause a full break in current work; context switching is notoriously costly for programmers
small Code Reviews should not warrant an interruption of your work, because not reviewing them should not block anyone. they should be done when someone is actually idling or at a planned time. most of the time i’ll review small changes directly after a daily if someone mentions a small open pr before starting with my actual work, i definitely prefer this to people just merging things and losing the chance to ask questions.
I find it frustrating when I get a review request that has nothing complex
when is a change complex enough to warant a review and how do you ensure that no complex change is merged without a review?
Sounds the real issue is that work is poorly defined if it comes to a standstill if no one is available for a 2 minute review.
those 2 minutes reviews are noise at the end of the day, if you ask me, they don’t have a noticeable impact on the reviewers daily performance.
Am a dev at a company that produces code for many different companies and institutions and most of these seem to be problems on a project level to me and not really problems with a code forge.
Stuff happens in the wrong order. You know the PR. Commit 1: ‘Feature.’ Commit 2: ‘fix.’ Commit 3: ‘fix.’ Commit 4: ‘actually fix.’ Commit 5: ‘please.’ Commit 6, made at 11:47 PM on a Thursday: ‘asdfasdf’. This person has a family. This person has hobbies. This person is, at this moment, crying. You don’t want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
I don’t care how other people use their branches and i don’t want my commits refused, if i can’t commit quickly before leaving my pc than the risk that someone else cannot pickup my work the next day increases. not having something in a shared repository is worse than having it within an ugly commit. And if you are working with atleast one other person, you should not directly push to main or the equivalent of your VCS. the only things we use pre-commit hooks for is running a code formatter. We run commit lints on PRs, because we generate changelogs from commits on PR-Branches and the PR-Branch is the only branch where commits matter to really anyone. but i can run a big chunk of our tests locally, so i can be reasonably sure that a PR-Pipeline won’t yell at me, if i bothered to cleanup my branch before making it someone elses Problem.
PR approval is too boolean. The PR is approved or it’s not approved. Real code review, like real life, lives in the middle. ‘Sure, fine, we’ll deal with it later’ is a legitimate human response and should be a legitimate button. Gerrit has a better model for this. If I weakly approve something as a maintainer, let me flag it for later.
i don’t see what problem this would solve, if a pr introduces an issue or accumulates some form of technical debt, create another issues for that, if you still approve the code to be fit for your main branch. I don’t want stuff to be just thrown onto a “for later”-pile, that should be a conscious decision.
PRs are too inflexible. I don’t need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type ‘LGTM’ could fund a moon mission. A nice one. With legroom. Let me customize and more easily control this. If the person is a maintainer and the LLM says its low risk/no risk just let them go.
your seniors don’t drown in dozens of tasks? sounds magical :D
and other than that: Code Reviews are not (only) about checking the code for some vague quality metrics, they help to keep knowledge about the thing we are building fresh in multiple heads and are an opportunity to teach each other or atleast discuss things with a concrete example. without human reviews the risk for knowledge to be stuck in a single head rises.
Stacked PRs are just better. They’re easier to review and understand. They have to be a first-class citizen not an add-on through a tool other than your VCS.
what are stacked PRs? prs depending on one another? i’d rather try to not need those by splitting work into small enough chunks, and if i end up needing those prs, because sometimes we do a bad job with defining those chunks, they should target a feature branch which is later merged into main, when it contains all necessary changes.
A forge shouldn’t do everything. Issue tracking yes. Kanban board, probably not. Wiki? I doubt it. Everything tools always turn into crap. You add features when its easy to add features and then pay the maintenance price for those features forever regardless of their rate of adoption because now someone, somewhere uses them and you are locked in.
as long as i don’t have to create the same issue in multiple places and keep them in sync i don’t care. I kind of agree about the wiki, documentation should be as close to the work as possible and as simple as possible, at work that became either another repo or a subfolder with a bunch of asciidoc and .svgs for modeling work and user handbooks which we render to html. works good, barrier to entry is low so we can keep the docu up to date without much hassle and our customers still get those fancy pdfs they like, depending on the forge the wiki would work simmiliar, but our pipeline for this is essentialy just a bash script and is easy to integrate into whatever tooling the customer requires or whats in use internally.
My local copy of the repo should be a representation of the entire repo, not just the code. I should be able to approve a PR from the same VCS I use to check in the code. I should be able to go through my issues by looking through local files.
maybe you want to use fossil and not git. fossil looks super cool, but the world speaks git, so i sadly don’t have work experience with it.
on first glance it seems like the affected packages are not something someone outside of redhat would use, so i guess the fallout of this will be more interesting than the infected packages themselfs.
PS/2 was the standard connection type for mice and keyboards for a pretty long time.
turning this into a webapp is a fine choice and if it’s intended to run locally without sharing state with other players you can do this completly in browser with javascript no problem.
https://eloquentjavascript.net/ is a good book for learning js, that is freely available online.
Alien, that movie is 100% “this place sucks, we should never visit again”. Aliens just proves it right, because the place indeed still sucks and going back was a very bad idea.
something being “first” implies existence and the statement is wrong if the something does not exist.
“everytime i’ve met yetAnotherUser, they promised me all their money” on the other hand is true, because we never met and existence of a meeting is not required.
or to look at it in a more mathy way:
“For all X y is true” is false if an x exists for which y is false, if no X exists no X exists for which y is false and thus “For all X y is true” is a true statement, but your statement is “there is an X_i from the set X=X_j for which y is true” which is false if no X_i is in the set.
polish notation is fine, but the need to get rid of argument names is beyond me, and i don’t really get the need for the fork-operator, that thing seems redundant.
yep, a team with “enough” workers when everybody is there and not sick is understaffed, working in those teams can become a nightmare the whole year round.
and for questions the colleague does not know the answere to? we are atleast two people with a functioning brain, we can figure stuff out. Most of the time if a new dev asks me something and i have time, i’ll comb through docs with them or we debug something together even if i am pretty sure what’s to do, because i don’t want to become a search engine for my colleagues, i want colleagues who can figure stuff out, so i’ll show them how I figure stuff out, and I learn stuff along the way pretty often doing that.
if I don’t have time I probably have some links that should lead to answeres and often enough a time window later in the day where we can talk, just because its christmas time and most of my meetings are cancelled :D
but christmas shift is imho pretty great for new team members (unless it collides with vacation plans, because the job switch was rather sudden and no one else is there), atleast here it tends to slow going, not many meetings and we get to do stuff that accumulated over the year that we wanted to do, but couldn’t for various reasons, so there are enough tasks for which you’ll see a lot of the code base and colleagues actually have time for pair programming and such.
and christmas itself is 2 and a half holidays in germany, so that helps too.
Users are mostly not programmers or anything related and will only notice bad quality, when it has piled up for a longish time, because they only observe the consequences of bad decisions and practices and don’t experience what bad code impacts first: the work on the code itself and the ability to add new functions or correct mistakes made.