> Well Y Does Some Of That yes but tangled.org really does do most of that! 1. JJ as the VCS: tangled supports stacked PRs using jj change-ids. https://blog.tangled.org/stacking , we use it a lot to build tangled itself: https://tangled.org/tangled.org/core/pulls 2. Raspberry pi as a forge for a long time: also check, the git server shim is super lightweight, its just an XRPC layer over git repositories + an sqlite3…
If I could make my own GitHub
141–150 of 160 posts
Re: If I could make my own GitHub
#142When the solution becomes the problem, an opportunity for disruption opens up. Lots of chatter around this right now. I'd be curious to see if any of the many alternatives popping up gain traction before Github course corrects.
I'm building my own tools. I think people should build their own tools. The future might look something like instead of paid software or open source software what you get is a set of requirements documents for a code forge, like a recipe. You bake your own. Then you alter it to your particular use case and set of preferences.
Some of the drawbacks include:
1. The time & effort you spend dicking around making something you could buy is time & effort not spent on your core business 2. Understanding what to build is not trivial. Sure, the tool you built works for your use case, but does it work for other teams? CS? Legal with all their fiddly requirements? Congrats, you're a product manager now. 3. Understanding what to build is not trivial. Jira is not a trivial CRUD app, it's a workflow engine builder. 4. User training and support is not something you can prompt away. The minute your software gets in anyone's critical path, you're on the hook for a lot of handholding. Congrats, you're user support now 5. Congrats on your new role in ops and getting called when stuff goes down
Any software engineer will tell you writing code is the easy part. Believe them lol.
Re: If I could make my own GitHub
#143Earlier quoted context omitted.
I started Free.ai as a weekend project with the same mindset. And a month in the work hasn't stopped. So I second this. Just find a good name, it helps.
gitwheel.com
From unregistered domain to website in hours.
I should have registered it myself.
Re: If I could make my own GitHub
#144Earlier quoted context omitted.
I was in camp 'boolean', but I think this has convinced me. I always had a problem that there were developers who didn't really understand the code, but would click 'approve' anyhow because they didn't see any problems in the parts they understood. This meant that they were completely unable to actually 'approve' a review, but were only able to reject it. They were juniors, so they'd eventually get to that point, but…
Either the code gets merged or it does not. That's the inherent boolean part. Given that, what's wrong with simply commenting on the PR to document the concerns, issues, lack of knowledge, etc? Unless you're using those +/-2 to achieve some sort of goal... but you can also do that with labels, tags, etc. on the PR.
sometimes I review something and say "approved", but sometimes I can only review part of it, and really need someone else to check what's out of my wheelhouse.
sort of "partially approved".
I have used systems that can set things like "requires 2 reviewers" or "bob, fred are required reviewers, elon and sam are optional reviewers".
also we had "thumbs up, thumbs down, and some comments might have a "task" associated with them as a required fix before approval"
optionally, maybe before you say "approved" you have an overall comment, and see the comments of other reviewers.
Re: If I could make my own GitHub
#145Earlier quoted context omitted.
I'm building my own tools. I think people should build their own tools. The future might look something like instead of paid software or open source software what you get is a set of requirements documents for a code forge, like a recipe. You bake your own. Then you alter it to your particular use case and set of preferences.
That's fine as a hobby, but it has massive drawbacks in a professional setting. If you know what you're getting into, sure, but otherwise you're gonna have a bad time. Some of the drawbacks include: 1. The time & effort you spend dicking around making something you could buy is time & effort not spent on your core business 2. Understanding what to build is not trivial. Sure, the tool you built works for your use case…
Here's the thing: I don't think so in the age of LLMs.
>I’ve noticed that people who have never worked with steel have trouble seeing this—that the motorcycle is primarily a mental phenomenon. They associate metal with given shapes—pipes, rods, girders, tools, parts—all of them fixed and inviolable, and think of it as primarily physical. But a person who does machining or foundry work or forge work or welding sees “steel” as having no shape at all. Steel can be any shape you want if you are skilled enough, and any shape but the one you want if you are not. Shapes, like this tappet, are what you arrive at, what you give to the steel. Steel has no more shape than this old pile of dirt on the engine here
Like the common person vs. a metalworker thinking about steel I think we've all gotten this rigid view that software we work with is fixed and unchangeable and the LLM boom is going to change that by making ALL of the software we use "any shape we want".
I think libraries and open source software are going to have to move to looking more like building blocks with standards and instructions for modifications and people are actually going to DO those modifications to suit themselves instead of just being satisfied with whatever their SaaS providers want to give them.
And the pendulum of "we don't do it because it's not our core competence" is going to swing back to having developer tools teams that actually build and maintain developer tools.
The old advice about the time spend writing your tools is tempered by the fact that LLMs make it very very much easier for a focused smart team to build things.
Re: If I could make my own GitHub
#146> This person has a family. This person has hobbies. This person is, at this moment, crying. Reminded me one benefit of email-based workflow. If I started receiving email, that's usually because I'm in the right mood to doing so. In such mood, I'll be more focused because I expect nothing else to interrupt my work. My problem with notification is that there's a pull towards clearing them as they show up. But there's…
A email is a notification,so how you are in the mood when it will come.can you elaborate clearly
Or, just like what @atrus said, don't receive emails if you have other higher-priorities.
Re: If I could make my own GitHub
#147Earlier quoted context omitted.
Well, if you are building one you generally want to support the 99% workflow, not the experimental one. What part of gerrit is so different? Stacked PR’s work fine right (not in github, as a concept)
The number one thing that gerrit does that is important is keep comments tied to the code between commits. By which I mean the discussion doesn't get broken between changes, and it makes it far more trivial to iterate on things in the review without breaking the discussion. And for the reviewer to see what's changed between revisions at the specific comment point they're looking at. And then have a nice clean commit…
Re: If I could make my own GitHub
#148Earlier quoted context omitted.
Graps seems neat in the way it forces you to sign your commits (which should really be standard practice) but I think Github itself has proven that interoperability is not that important.
In Radicle all code and social artifacts (issues, comments, patches etc.) are signed by default.
Re: If I could make my own GitHub
#149I recognise myself in this post without having realised it previously. The PR review process is flawed, it adds something, but maybe not what it intends.
One of my issue with the PR process is the way they are focused on comments first, instead of the code. You also have the same issue that email threads have, if you comment something substantial, with details you pretty much always get a response that will take one small point, and sort of ignore the rest. I also hate how noisy the discussion part is, and how GitHub handles that noise by just… hiding part of the disc…
Re: If I could make my own GitHub
#150> PR approval is too boolean. The PR is approved or it's not approved. Real code review, like real life, lives in the middle This is have-your-cake-and-eat-it. PR approval is a permission so is a boolean. Of course it is. Either the code can be merged or it can't. What's being described really here is just something to make you feel slightly better about yourself whilst approving code you hate ("we should revisit thi…