Re: [jgit-dev] RE: [egit-dev] Rewriting JGit history and standard commen

["Shawn O. Pearce" <spearce@xxxxxxxxxxx>]

Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx> wrote:
> > Its things like this that just seem f*cked up about Eclipse.  A lot
> > of the processes and so forth appear to be built up to verify that X
> > gets done, but they are some of the most inefficient ways to reach
> > that goal.
...
> I know Wayne Beaton is investing time into things like IP Log automation. We
> don't have the resources to magically make all the pain go away, but we are
> steadily and incrementally improving things.

As you pointed out in the section I clipped, a lot of this is caused
by board directive.  Wayne can only do so much to improve things
on his own, he's 1 guy, with a lot on his plate, and he's bound by
prior board decisions.

I do appreciate Wayne's efforts.  Most of my remarks have been about
stuff that I believe predates Wayne.  For example the automatic IP
log PHP script that is used by most projects today.  When that was
put together, I don't see how it helps the IP team complete their
reviews much faster.

Given that we know the IP review team is limited in size, budget,
and time, and that their workload is increasing at an incredible
rate, things need to be made more streamlined and automated, not
tell projects to wait, or to continue to enforce current practices
which don't scale.
 
> But there is no denying that there is overhead associated with being an
> Eclipse project, as opposed to (say) SourceForge or Google Code. But there
> is value in being at Eclipse as well. At least there is for most projects
> here. 

I don't deny there is overhead.  I'm complaining about that overhead.

The value to EGit is to eventually be part of a release train.
That's why we moved here.  We wanted to make Git available out of
the box on major Eclipse distributions.

JGit is here only to make it easier for EGit to integrate new
versions, since its so dependent on it.

So, sure, there's some value.  But its a fairly small thing to me
relative to the current pain.  :-\
 
> The typical reason why the IP team talks with committers on private email is
> not because of secrecy, although that happens occasionally. The reason is
> that they are supporting 150+ projects, and each dev list requires that you
> be subscribed before you can post.

I guess the mailing list software we're using doesn't permit EMO
employees to subscribe for posting, but without delivery?  Filtering
everything to /dev/null might also be possible, but it gets harder
because you have to filter all lists except maybe a handful.

I just find it horribly awkward that they aren't able to communicate
with the entire project community.

> (That's done to reduce spam on the lists.)

The folks behind vger.kernel.org do an amazing job at this.

The main git and kernel mailing lists are open posting, and have
fairly low spam counts.  I think I see about 1 spam per week on the
git mailing list that makes it through their filter.  And that list
is pretty well advertised on the Internet.

I hate to say it, but I think that's also a volunteer operation.

Open posting lists make it a lot easier for a community to bring in
new people.  Or talk to an infrequent contributor (like EMO staff).
Just saying.

> > Basically I read EMO's header request as "[...]"
> 
> Gosh. I've never thought about it that way. Eclipse projects have had
> standard file headers for their code since even before the Eclipse
> Foundation came into existence. I believe that other open source foundations
> such as Apache and Mozilla follow similar practices.

I don't disagree with standard file headers.  Even JGit has
maintained a standard file header since its inception.  The only
project I know of that doesn't is C Git.  Weird, I know.

> But if this is some
> enormous burden on projects that we've just never been aware of then we
> should at least look at the issue. It's always possible that we're enforcing
> a valueless convention out of habit.

The primary purpose of the header is to declare the license of the
content contained within that file.  Most courts/laywers/reasonable
people seem to have come to the agreement that by putting a
consistent header on every file of the same project, its clear what
the terms are for use/reuse of the contained content.

Projects (or project umbrellas like Apache) have come up with their
own standard header which makes those terms as clear as they think
they need them to be.  Its a good practice, even when your code
is practically in the public domain.  IMHO, its better to be clear
than to be vague about your terms of use.

I don't think its a burden.  If I did I wouldn't have insisted on
it within JGit or EGit all of this time.

What I think is a burden is the template EMO gave us, vs. the header
we already have.

Compare what they gave us earlier in the thread [3,4] to what
we have now [5].  Identical.  Except for that first paragraph,
license title, and extra copyright line in [3,4].  To me, that
first paragraph doesn't say anything beyond "read the following
paragraphs, thanks".

[3] http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg00104.html
[4] http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg00111.html
[5] http://egit.eclipse.org/w/?p=jgit.git;a=blob;f=org.eclipse.jgit/src/org/eclipse/jgit/lib/PackFile.java;h=3de2c242228fb7c899eda95b824409259bf32379;hb=046198cf5f21e5a63e8ec0ecde2ef3fe21db2eae
 
> > Interesting side note...  The EDL is *exactly* the 3-clause BSD but
> > with the University of California replaced with Eclipse Foundation.
> > Under US copyright law changing 3 words into 2 words gives me
> > the right to declare copyright over the larger contract?  Damn.
> > I never would have tried to do that, I can't see that as being
> > a tenable case of fair use, or something you can actually claim
> > copyright over.  EMO's got some brass ones.
> 
> Shawn, on this one you're just plain wrong.

I think I'm still right.  I think someone may have misunderstood
the OSI example in [1].

[1] http://www.opensource.org/licenses/bsd-license.php 

That first line, "Copyright (c) <YEAR>, <OWNER>" is *not* for the
organization issuing the license.  Its for the copyright holder(s)
of the content(s) of the file(s) that the license was attached to.

Asking us to include "Copyright (c) 2007, Eclipse Foundation,
Inc. and its licensors." as in [3,4] is a literal translation of
the OSI license in [1], without understanding the point of that line.

Yikes.  That scares me even more.


> In other words, we used the BSD license exactly in the way it is intended to
> be used. We further confirmed this with the OSI directly.

I think you might want to reconsider how the EDL is reproduced.

The foundation shouldn't be claiming copyright over the text
of the EDL.  Nor should it be claiming copyright on works that
it didn't create, and didn't have copyright assigned to it for.
But the proposed header almost seems to do that.

-- 
Shawn.