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

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

onsdagen den 10 februari 2010 23.34.20 skrev  Shawn O. Pearce:
> 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/ec
> lipse/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.

Me too. Someone might actually think Eclipse owns the code, when
it doesn't. I don't think we should do that. Or someone point to to
a place where a laywer explains this is detail. Groklaw?

-- robin