Hacker News Reader

Comment by pedalpete | Hacker News Reader

My hope and suspicion is this will have a significant impact on the number of improvements to open-source projects and particularly little things like js components.

Just in the last few days, I've come across a few very minor bugs, with a one-line fix. In order to make that change, I currently need to fork the repo, download it, make the change (turn off my prettier or adapt to the repo's) then make the PR.

I'm hoping with this I can just make a PR in the owner's package. It's the difference between a 10 minute commit and a 1 minute change.

View on HN

Github has had a built-in editor for almost a decade, you just had to click the Edit button in the file: https://github.blog/2011-04-26-forking-with-the-edit-button/ (the button has since changed look to a Pencil icon)

This is not to disparage you, just to note that it may not have such a great effect.

GitHub's editor is useful for simple fixes, (formatting, markdown, typos,) but Codespaces seems extremely useful in building a reproducible dev environment for more complex packages / projects, including build tooling!

Yes but OP was talking about simple fixes in the first place

Even simple fixes often need to be run/tested before a PR can be put up with confidence.

a one minute change isn't ran or tested, almost by definition.

If you could have a fully-functional dev environment with pre-installed dependencies in 10s and the package takes 48 seconds to build and test, then you could.

Wrong

I'm aware of several places in my team's codebase where you can change a couple of characters and break the entire company if you didn't test the change.

There's a very big difference between editing a file in a textbox and editing a file in an IDE pre-configured to have all the correct dependencies, extensions, build&test scripts, intellisense, etc.

Of course there is! But if it's literally one line...

The set of single line changes I'd be comfortable making with full IDE support is much larger than the set of one line changes I'd be comfortable making in a text box.

You still have to fork

Because implementing a shadow fork is sooo hard.

You must be fun at parties

I think you missed the part where i was being positive to new ideas and not just being a pointless debbie downer.

I feel like even with one-line fixes, having the tests run before committing (to see the CI/CD results instead) would give people a lot more confidence in making those changes.

Personally speaking, I'd be worried that I end up making 15 commits to get everything right and the history in that PR would be slightly embarrassing. Having the live linting, intellisense and tests makes pushing a single commit a lot easier.

That was already possible with Travis CI though. Not sure how the situation is now, are they still up and running?

The difference is habbit.

We are not in the habbit of doing this now.

This change may change that habbit and encourage a new one.

Im not saying it will, but its naive to brush literally every suggestion off because you can already do something similar.

At least think it through before making a judgement on a new idea.

The edit button is perfect for fixing typos; I don't think I've ever even used it for any other purpose. Tidying-up typos up as you're passing through is a small way in which anyone can help contribute! It's like picking up pieces of trash as you're strolling through a park.

a bit of a noob question. I'd love to be able to tweak code on the spot. Like I'm showing something to my boss and he wants something quickly adjusted, I write a couple lines, commit and then with Github Actions I get back an updated executable immediately

But I feel like things are set up explicitly to not work this way. Maybe I'm doing something wrong but can you trigger a rebuild of a prerelease?

It seems you need to setup a new tag and a new release version to ever get a rebuild. There are explicitly no official Actions for updating releases. A new release for a one line change seems a bit crazy (and you'll get a huge clutter of releases which is confusing for users)

I tried to ask and was told it's maybe possible if you write an action yourself .. yikes https://github.community/t5/GitHub-Actions/What-s-the-canoni...

You can set up your actions to build an executable for each commit on the master branch, it will be available as an artifact in the actions tab. This is useful if you want to test your built code.

Generally speaking, you shouldn't modify existing releases, since somebody may have downloaded them and he will have no way of knowing you have improved them.

I guess you're right. That this is the expected workflow. The way the UI by default dumps Prereleases and Releases together (with very small faint font to distinguish them) in the same tab called "Releases" is an issue so I sorta understand why you feel it'd be confusing. The UI is no good, but this is not an insurmountable problem

It's true you can have a latest artifact.. I will try using that - but I can't email a colleague and tell him/her to download an artifact. There is no "latest build action artifact" page and there is so much extraneous information that if they've never used github you'd need to attach an explanation of where to click.

I didn't feel my use-case was particularly unusual, but I guess it's doesn't fit Github's model.

Yeah, where this gets really interesting is in the integration with the project's build system, CI, and test environments.

I'm envisioning a project with a full automated build and test suite with an on-demand staging environment for each change (the k8s docs project does this, at least it did the last time I chucked a typo PR over the wall).

With proper integration to the editor you could have an extremely slick dev environment instantly available for any casual passerby. Once implemented, this would greatly simplify maintainers' lives as well!

Hopefully the licensing requirements can be made simple as well!

I recently wanted to submit a 3 character change to golang that significantly speeds up strconv.ParseFloat(), but lost interest about 2-3 minutes into reading this: https://golang.org/doc/contribute.html

That seems outside of the scope of an in-browser text editor...

Sure - I'm just venting. I found something trivial that makes a small difference, but the contribution process was overly cumbersome.

To the parent poster's point, I feel if I could easily submit even a small subset of the trivial changes I have sitting around in local forks, it'd greatly improve several projects.

Why not post the change here so someone else could contribute it? Sounds useful.

That'd be awesome!

    diff --git a/src/strconv/atof.go b/src/strconv/atof.go
    index 28ad094..49cec69 100644
    --- a/src/strconv/atof.go
    +++ b/src/strconv/atof.go
    @@ -410,12 +410,12 @@ out:
     }
     
     // Exact powers of 10.
    -var float64pow10 = []float64{
    +var float64pow10 = [...]float64{
      1e0, 1e1, 1e2, 1e3, 1e4, 1e5, 1e6, 1e7, 1e8, 1e9,
      1e10, 1e11, 1e12, 1e13, 1e14, 1e15, 1e16, 1e17, 1e18, 1e19,
      1e20, 1e21, 1e22,
     }
    -var float32pow10 = []float32{1e0, 1e1, 1e2, 1e3, 1e4, 1e5, 1e6, 1e7, 1e8, 1e9, 1e10}
    +var float32pow10 = [...]float32{1e0, 1e1, 1e2, 1e3, 1e4, 1e5, 1e6, 1e7, 1e8, 1e9, 1e10}
     
     // If possible to convert decimal representation to 64-bit float f exactly,
     // entirely in floating-point math, do so, avoiding the expense of decimalToFloatBits.

math.Pow10() already uses arrays this way, and I found a ~10% performance while optimizing an alternative float parsing implementation by making the same change.

I just want to say kudos and well done to post the diff here.

Didn't you just poison this change and ensure that it can never be applied? Having posted this anonymously, nobody can sign the Contributor License Agreement and promise truthfully that this is original code that they have the rights to contribute. Including yourself, in the future.

You can not copyright the ... (dot dot dot) nor can you claim copyright to an existing work by adding ... to it. You might be able to pattern it though...

I don't know the specifics of Google's contributor agreement (you need to log in with a Google account just to read it), but in my experience they are much stricter than copyright law. I've heard of organizations that would like to force people to sign contributor agreements just to be allowed to open GitHub issues. Because the issue might contain information that might taint everything. At least in the view of corporate lawyers.

Technical advancements are always held back by politics. This is one of the main advantages of GPL, there is no CLA to sign.

CLA's are imposed by companies, not licenses. I'm quire sure that companies with OSS projects under GPL licenses would still want external contributors to certify that the code they contribute is theirs to contribute and can legally be licensed as GPL.

Indeed, there is the Developer Certificate of Origin for that:

https://developercertificate.org/

Sure there is: https://www.gnu.org/licenses/why-assign.html

The owner of a GPL project doesn't own the copyright for contributed code (and therefore can't license it themselves under GPL), unless they receive a copyright assignment.

Or syncing a local fork before you can edit against master and PR back. I wish syncing a remove/local fork was simpler.

Reply on news.ycombinator.com