Notice: sr.ht is currently in alpha, and the quality of the service may reflect that.

Are these all different services? Seems like quite a hassle. Like a split of project resources.

An alpha classification doesn’t spark confidence in using it productively and for significant projects.

Unfortunately, I find the need to have an account in order to contribute to projects a deal breaker. It causes too much friction for no real gain. Email based workflows will always reign supreme. It’s the OG of code contributions.

After opening with a need to be open-minded, this seems quite close-minded. Sure, it’s their article. Still, I was hoping for a more neutral and substantiated advocating and description.

I certainly didn’t feel like it answered [all] my questions and concerns in multiple sections.

I somewhat like the idea of being able to submit issues via email directly. It does cost on spam classification and prevention, though. An account is easily classifiable as an additional confidence metric. E-Mail, not so much, or with significantly more complexity in relating data and ensuring continuity of source.

An account is a very obvious way to build a reremovedtion. If you see a new GitHub account submitting a PR vs someone having contributed for a long time and significant projects in the same technology, you may approach the reviews quite differently. It is, at least, a very useful and simple way to classify authors and patch submitters.

What does SourceHut provide in this aspect? To what degree does it verify incoming emails authenticity, sender source, and continuity of source hoster? To what degree does it relate information by email address? I assume it does not.

Supporting soft subs is a complex topic though. Three formats, font embedding, positioning and animations. It’s a ton of effort, and anything less than “full featureset support” will mean they don’t render how you design them in your full-set editor and local media play. And there will be differences and bugs, at least for a while. I suspect font rendering with various fonts in a media render context will have it’s own set of issues.

I also think it’d be nice, but I can totally see how it may not make sense technically (complexity with its burdens vs need) or economically.

Browsers are already absurdly complex though so… maybe? :P

RE: phabricator…I don’t know what that service is or is for, so I can’t comment if there’s any proof therein.

The how to submit a patch section documents that that’s where they accept patches. And they do their reviews and change iterations there. By necessity, that also means hosting/having the repos.

That’s confusing to me.

They only accept patches on Phabricator, have the sources there, but suggest using GitHub, but afterwards Phabricator to submit the changes?

I can only imagine it’s to lower barrier to entry because GitHub is more well known. But this just seems like a confusing mess to me, without clear wording of intentions and separation of concerns [in their docs, not your post or comment here].

When I searched for text “github” I did not find anything. But searching in the inspector to cover urls:

Firefox and related code is stored in our git repository.

Which makes it all the more confusing. Stored there, but patches only elsewhere?

Really, for a “moved their sources” claim I’d prefer some form of announcement or docs that describe this.

These changes will apply to operations like cloning repositories over HTTPS, anonymously interacting with our REST APIs, and downloading files from raw.githubusercontent.com.

That’s a read-only mirror, not a “move onto GitHub”.

PRs get automatically closed, referring to the contrib docs.

• https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html
• https://phabricator.services.mozilla.com/

Lenard Flören, a Germany-based art director at an advertising agency, said he quickly realized that trying to create his dream fitness app with one lengthy prompt would lead to a plethora of bugs that “neither ChatGPT nor my clueless self had any chance of solving.”

If everyone can create programs, and everyone fails, maybe it’ll bring increased appreciation to development and good development and products? One could hope. I guess the worst offenders won’t even try themselves either way. The services are not that accessible.

I’ve aired my frustration about the terminology previously; anyway, I’m trying to accept the terminology in the interpretation it could make some sense:

You tell the AI the “vibe” of what you want the result to have, and it does that - but of course it’s not necessarily that simple. You may end up doing prompt engineering, multiple iterations, trial and error, etc

When we tried a product at my workplace generating a web app prototype in react seemed viable and reasonable, possibly good for prototyping and demonstrating. We also tried a Blazor app, and it utterly failed. I suspect because of less training on it and much more complex mixture of technologies.