Live data from Hacker News

Apache Software Foundation joins GitHub open source community

github.blog

121–130 of 255 posts

Re: Apache Software Foundation joins GitHub open source community

#121

Earlier quoted context omitted.

You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. > Adding a remote is generally a one-time cost It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.

> You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. Having to create a fork per PR is a rather antiquated way of doing it. In my experience, you can almost always push to origin and create a new PR from the branch, but maybe I've just been lucky with the projects I contribute to. > It's not a constant cost, unless you're saying you only ever intend to contri…

> you can almost always push to origin

Why am I having to repeat myself here? You can never push to origin unless it's your own project or your team's project.

> It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay [...] N times, where N is the number of projects you contribute to.

In other words, it's not a constant cost.

Re: Apache Software Foundation joins GitHub open source community

#122
Apparently, one of the big motivating reasons for this was "cost".

> The foundation’s 2018 five-year strategic plan noted that infrastructure services account for more than 80 percent of the total ASF expense budget, adding: “Increasingly, project communities have infrastructure requirements that strain the capabilities of the ASF.”

> The report noted that, given burgeoning costs, encouraging the use of more externally provided services was its best option. (“Using a simple growth forecast to project expenses and effective governance and mentoring to ensure that using externally provided services does not in any way present barriers to entry to projects or reduce transparency, inclusiveness and diversity.”)

https://www.cbronline.com/news/apache-software-foundation-gi...

Given that I find ASF has always been very moral with their fundraising and careful with their money (unlike a couple other major non-profits I happily would name in any other context), as disappointed as I am with this decision, it is difficult for me to blame them for making it: git is extremely difficult to scale correctly (due to its reliance on interactive protocols), which led Google Code and then GitHub to rewrite large portions of it (of course, as closed source internal-only this-is-our-competitive-advantage projects); when you are a small non-profit, knowing that you would have 5x the resources for staffing if you just swapped out some mere tooling has got to be a really really tough choice for something that isn't quite your core moral (as it would be with say, the FSF).

Re: Apache Software Foundation joins GitHub open source community

#123
post #93

Earlier quoted context omitted.

It's hard when you have lots of folks jumping into a code review, and you don't want to duplicate effort or you want to rapidly iterate on your code. You know those email chains that just continue to fork? Where people reply to the original (or the first couple replies) with their wall of text after a couple other replies have already trickled through? That's what a collaborative, stateful PR solves.

Everyone is trying to get me to defend mailing lists. I have no idea why. I haven't said anything about them. In fact, I hate mailing lists.

> I haven't said anything about them.

> # now attach/upload bugfix.patch

Where do you "attach" your patch file?

Also, if it's not GitHub/GitLab/gerrit/reviewboard/etc. and not mailing list, what other workflow for code contribution are you talking about then?

Re: Apache Software Foundation joins GitHub open source community

#124
post #53

Earlier quoted context omitted.

Hmm based on this, the .org tld and the server providers can have control over the project too. Right? If so, we should use an open source distributed protocol.

> Hmm based on this, the .org tld and the server providers can have control over the project too. Right? No, pretty obviously not. For the domain, this has already been answered. For the servers, it's trivial to move your setup to a different hoster with no visible effects to the outside. > If so, we should use an open source distributed protocol. Like ... git and email? Yeah, we should.

Git and email isn't sufficient, surely you need a repository as well, a listserver in your implementation I guess?

Re: Apache Software Foundation joins GitHub open source community

#125

I hope projects will get rid of JIRA now!

I recently moved to a company that uses Jira. What kinds of problems should I be looking out for?

If it's the cloud hosted version (I can't speak to their on-prem software since I haven't used it in a few years), watch out for the nonsense that is having two separate markup languages, used it two different contexts. The original "Atlassian markup" (made famous by Confluence) is used, as best I can tell, in issue creation and descriptions, whereas some kind of Markdown hybrid is used in issue comments

Be careful if you use subtasks for issues, which may sound like a perfectly reasonable work breakdown idea but subtasks are snowflakes in Jira and become very hard to have visibility into, assign points to, etc

The rest of the rant I'll omit, since it's more rooted in my personal hatred for their products and has less substantiation

Re: Apache Software Foundation joins GitHub open source community

#126

Earlier quoted context omitted.

> You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. Having to create a fork per PR is a rather antiquated way of doing it. In my experience, you can almost always push to origin and create a new PR from the branch, but maybe I've just been lucky with the projects I contribute to. > It's not a constant cost, unless you're saying you only ever intend to contri…

> you can almost always push to origin Why am I having to repeat myself here? You can never push to origin unless it's your own project or your team's project. > It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay [...] N times, where N is the number of projects you contribute to. In other words, it's not a constant cost.

>why am I having to repeat myself here

Because you are incorrect and not reading the responses.

>you set origin to the branch you own...

Re: Apache Software Foundation joins GitHub open source community

#127
post #52

Earlier quoted context omitted.

I guess gitlab is the same. The important flow is that there's a very easy way to fork and send a pull/merge request.

"Easy" like: git diff master..bugfix > bugfix.patch # or `format-patch` # now attach/upload bugfix.patch Instead of: # make sure you click around github.com to create third fork git remote add unnecessary-third-fork $THIRDFORK git push unnecessary-third-fork bugfix firefox $THIRDFORK # now click around to file a PR # now wait for your PR to be merged # now click around on github.com to delete $THIRDFORK # ... unless…

I used patches and lists before, a lot. It was either hard or impossible to track more than one at a time, in context and with lots of conversations around specific lines of code. It was also a nightmare for maintainers to constantly want to tell people to rebase their patches based on other people's patches. To link patches to other patches to issues, etcetera.

The Github website and its fork/pull request flow has increased my productivity and the amount of things I contribute to or can maintain with some level of sanity 100x easily.

Re: Apache Software Foundation joins GitHub open source community

#128
post #119

Earlier quoted context omitted.

Can you clarify the flow that doesn't involve github and also doesn't involve mailing lists?

You could upload the .patch to something other than GitHub.

Yes, exactly. Literally anything that has an upload button in the bugtracker for you attach your patch that fixes the bug.

Re: Apache Software Foundation joins GitHub open source community

#129

In 2009, I brought the idea of using github up on the members@ list and was called a troll. Agreed, at the time, the message was trolling... https://imgur.com/a/JPQtCQ4 I brought it up again later in 2010 and 2011 on the members@ list too. Lots of discussion with the general consensus that it wouldn't happen because it isn't an 'open' platform. I even wrote a blog post about it in 2011, which was also discussed on me…

Congrats.

Re: Apache Software Foundation joins GitHub open source community

#130
post #95
post #72

Earlier quoted context omitted.

Just for the historial record: Bitkeeper is much older than both git and Mercurial, hence Bitkeeper can not be said to have taken ideas from Mercurial. Both was sprung in large parts from Linus' description of what requirements he had in order to consider using a version control system for Linux.

I think the comment meant that git took ideas from Mercurial rather than BK taking ideas from Mercurial.

Git start before mercurial.
Post reply on HN