Live data from Hacker News

Apache considered harmful

mikealrogers.com

121–130 of 171 posts

Re: Apache considered harmful

#121

Earlier quoted context omitted.

I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server. There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase. Granted, I'm scared to de…

There is no issue with the size of the local copy. Most of the times the entire git repo is smaller than single SVN checkout.

I don't think I've ever seen a situation where that's true. And I've converted a lot of repositories (I maintain the svn2git project). SVN has its metafiles, but git has the full history locally. In all but the most trivially-sized projects, the git clone is bound to be larger. For larger projects it can be several orders of magnitude larger.

Re: Apache considered harmful

#122

I'm curious as to the average age of committers by project under the ASF vs. popular projects on github. My hypothesis is that they would be older by a significant margin.

I think you're right, but they overlap too, so hard to give a completely clear picture. I.e., every Apache person I've met also uses GitHub. Obviously the converse is not true.

Re: Apache considered harmful

#123
post #69
post #21

Earlier quoted context omitted.

Sorry, explain to me clearly why that is the One Answer and we must stop discussing alternatives? You're answering a question I'm not even remotely asking.

There isn't One Answer. The point is, you have plenty of alternatives. I don't know why the patch hasn't been applied. I know how I can find out though: I can join the developer mailing list and ask. If that doesn't work, I can track down a developer directly (they're not hard to find once you're on the mailing list) and bug 'em until I get a decent response. If it's clear the maintainers aren't doing their job, rais…

So you do agree that there are options beyond forking it or merely "raising a ruckus on the mailing list". My point was precisely that there are additional answers and that just glibly saying "Well, just fork it or accept what the mailing list result is" isn't a good summary of the alternatives, and in the context of what you were replying to borders on deceptive.

In the meantime, the fact that I am rich with options doesn't negate the original discussion, which is that the Apache processes are becoming distinctly suboptimal for the context they work in. The fact that I can just take the software and run with it doesn't fix their processes, and the fact that anybody can do so doesn't excuse broken processes. The fact that we can fork does not mean everybody should just stop discussing Apache processes; it doesn't follow.

I'm still in context: "I was was almost driven to start blogging last week by ASF's poor job of maintaining its projects. There was a small bug in Solr. I was not the first to find this bug, and someone had not only reported the bug, but filed a patch on the bug tracker a year and a half ago. The patch was never merged in, nobody provided any feedback as to why the patch wasn't merged in." "You can just fork it" is not an answer to this problem. I'd say in its own way it's a disguised confession that in fact the problems with the project are indeed so bad that your only hope is to fork it yourself. Well, that still says bad things about the project, regardless of whether I have mitigation options.

Re: Apache considered harmful

#124
post #78

Earlier quoted context omitted.

I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server. There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase. Granted, I'm scared to de…

You can, but SVN more or less forces you to.

Which means that if a developer wants to do do git-like stuff (say sharing a patch with a single other developer or committing a day's unfinished work to an alternate backup site), then he's just going to have to work around the SVN tool to do it.

The tool should exist to serve the people producing the work, not the other way around.

Re: Apache considered harmful

#125

Earlier quoted context omitted.

I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server. There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase. Granted, I'm scared to de…

There is no issue with the size of the local copy. Most of the times the entire git repo is smaller than single SVN checkout.

An up-to-date snapshot of my source tree at work is several GB. The whole Perforce repo is probably 100GB. Most of that is vendor libraries. For example, every so often we update to a new version of the Boost C++ libraries and pre-build it for most common platforms. This amounts to a GB or two. This is easier on the other developers and it makes the process more repeatable for QA.

One of the great things about Perforce is that it's normal practice to map only selected subtrees of the repo. So I have several workspaces going at any one time.

As much as I am impressed with git's speed, this would not work with git. I used to try to managing Boost's vendor drop as a git repo. I now just keep my notes in there about how to download and build it locally.

Re: Apache considered harmful

#126

Earlier quoted context omitted.

There is no issue with the size of the local copy. Most of the times the entire git repo is smaller than single SVN checkout.

An up-to-date snapshot of my source tree at work is several GB. The whole Perforce repo is probably 100GB. Most of that is vendor libraries. For example, every so often we update to a new version of the Boost C++ libraries and pre-build it for most common platforms. This amounts to a GB or two. This is easier on the other developers and it makes the process more repeatable for QA. One of the great things about Perfor…

I think the idea is to use git submodules for vendor libs. Anything you're not modifying and a 3rd party is maintaining should be a submodule; that way you don't keep any of those changes in the repo.

Re: Apache considered harmful

#127

Just to get two things out of the way: I'm an ASF member (albeit not very active lately) and a huge fan of git with or without GitHub. I'm one of the many people advocating for git internally at the ASF. I have been met with opposition in the past, but a lot of it has been around who's going to maintain the infrastructure, given it's a volunteer system. Let's just take it as axiomatic that the ASF is going to self-ho…

This is a good point. Anyone who starts an open-source project should, from day one, have a vetted Contributor License Agreement and ONLY accept pull requests that include signed CLAs (or from a person who has one on file).

Re: Apache considered harmful

#128

Earlier quoted context omitted.

An up-to-date snapshot of my source tree at work is several GB. The whole Perforce repo is probably 100GB. Most of that is vendor libraries. For example, every so often we update to a new version of the Boost C++ libraries and pre-build it for most common platforms. This amounts to a GB or two. This is easier on the other developers and it makes the process more repeatable for QA. One of the great things about Perfor…

I think the idea is to use git submodules for vendor libs. Anything you're not modifying and a 3rd party is maintaining should be a submodule; that way you don't keep any of those changes in the repo.

When a new vendor release comes out, we build it with our "official" compiler settings for the different platforms, branch the headers from the source and combine them into a convenient "SDK" tree, sometimes tweak something here or there, and update the document. Amounts to several GB being checked in from multiple machines. Occasionally a developer (usually me, but others too) needs to commit changes back to our central repo vendor tree.

I suppose we could do that into a separate repository and then define parts of that as a git submodule.

Hmm, reading http://book.git-scm.com/5_submodules.html I don't see how to do that with git without using 100 GB on the library dev machines.

Re: Apache considered harmful

#129
post #57
post #40

Earlier quoted context omitted.

That moment of thought was apparently too expensive for you; you didn't respond to the actual concern, but rather raised an argument suggesting that any argument about git must be meritless. I don't know who you expect to convince by baying at the moon. The ASF people are right in at least one sense: if you don't want to run projects in the ASF style, you are free to take your work elsewhere.

I need not respond to the actual concern because the ASF has already done so. The ASF has already decided to allow git to be used . I assume that their lawyers OK'd this change. So I did not intend to continue an ongoing discussion: ASF has already concluded that discussion and approved git. Clearly, jaaron does not represent the views of all the "ASF People", and for him to raise issues as legal showstoppers when th…

> 4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox")

You're jumping at shadows and putting words into his mouth. What he said was:

> Git is an impressive tool and github is awesome for what it is, but it's not a non-profit foundation and it won't replace one.

Which doesn't imply the same condescenscion as your "quote".

Re: Apache considered harmful

#130

Earlier quoted context omitted.

Git normally only allows you to edit unpublished history; the server can prohibit editing of published history. Similarly, svn allows history editing if the server permits it.

See Fedora's git repository for an example of how to do this.

I believe they use gitolite to do this. (https://github.com/sitaramc/gitolite)
Post reply on HN