This is the mail archive of the
mailing list for the GNU Fortran project.
Re: Original commit history for gfortran
On 06/19/11 10:03 PM, Tobias Schlüter wrote:
Thanks for the information
On 2011-06-18 14:39, "C. Bergström" wrote:
On 06/18/11 05:16 PM, Toon Moene wrote:
On 06/18/2011 12:12 PM, Toon Moene wrote:
On 06/18/2011 05:05 AM, Christopher Bergström wrote:
We're in the process of considering contributing to gfortran for a
special project, but when we started to vet the codebase we hit a
in lack of commit history.
Additional information is here:
The above gives you the history after the split from the g95 project:
in January 2003.
The original commit by Paul Brook of the gcc-g95 repository contents
to the GCC repository is here:
So I converted the cvs repo to git so I could actually dig and compare a
Here's an example of what we're trying to understand
This file wasn't in g95, but then magically appears in Paul's initial
# Unless I've messed up somewhere along my path..
# Was this file in gcc the whole time and just an external dep?
I think the history of this particular change went like this: Steven
Bosscher was concerned about making g95 more modular. Part of that
process was splitting the big g95.h file into several parts -- that's
where arith.h comes from. Another part of that endeavour was moving
the various tree dumpers into dump-parse-tree.c -- which IMO defeated
the original purpose of having them in their corresponding source
files (namely documentation), but on the other hand made that part
As for the history, there was another sourceforge project dedicated to
g95 -> gcc integration bsides gcc-g95, its name escapes me right now.
IIRC some of the I/O library was developed there.
Between the closing of g95's tree and gcc-g95's launch some
development happened in private trees as pointed out before, but apart
from that and Andy's very initial work which happened without CVS, you
should find all the history in public record.
I'm sorry that I'm writing the following paragraph, but I think I
should. I heard rumors that Andy was hired by Pathscale, so I'm a bit
worried about your intentions.
Why speculate or give credence to rumors - just ask if it's important to you
You're not trying to vet the code for the parts of the code which
are available to relicensing to Pathscale for commerical exploitation,
are you? That's something that may under very specific circumstances
be allowed by the usual copyright assignment? You will probably
understand that Andy's past behavior (including blatant disregard for
free-software licenses, Steve already told the story) might make me
question the behavior of people associated with him, even though I
feel very rude doing so, and even though you alrady expressed good
I'd rather someone be rude and honest than quiet and polite.
I can't say I really care about Andy's alleged copyright infringement.
(My general point on matters like this is litigate or shut up. We're
all here to get work done and licensing (licensing trolls and I don't
mean you) is the single biggest detractor from open source progress I
Andy started the project and at the time of the fork still was the
majority contributor. Cut the guy some slack for having a bit of ego
and wanting to maintain control. It's been how many years now and still
too much hard feelings. I'm biased but it's based on a positive working
Please put in google open source ekopath or pathscale and see whose name
and what news comes up.
(In the past 2 years I've directly been responsible for open sourcing
more code than a lot of people and moved PathScale to an entirely open
development model for x86.)
Now with that I'll play devil's advocate..
1) What's wrong with commercial software?
2) What's wrong if we strip out your contributions (20 patches if I'm
not mistaken) from g95 and use it in a closed commercial product? (See
more comments below)
There's a couple views I can imagine people will have
1) GNU/GPL - Using licensing to try to ensure contributions go back
upstream. To me this works a majority of the time, but not always. (I
think it varies on the project and circumstances. I have a personal
laundry list of companies I'd like to force to give changes in public,
but their products are so tightly controlled and I'm not a copyright
holder so can't do a damn thing about it. Then again even if the
changes were public they aren't likely going to get merged anywhere or
be useful. So who has time to care at the end of the day. Would you
believe I wanted PathScale to be open source before I ever worked here
and was blocked...)
2) BSD - No comment
3) Fortran HPC community as a whole - The majority of Fortran users I
know work in or around HPC. (I may be biased) With that I can't say
most of them care about open source at all. (Some do) They buy/use
PathScale/PGI/Intel and for the larger labs I'm not sure if they use
gfortran. (They may, but I really don't have that data) Most of them
want their code to compile, get best performance and sometimes use
F2K3. You're not going to stop them from buying commercially supported
In this case I serve the end user/community and not directly open
source. Why? Would it be good for Fortran if a F2K3 front-end was
freely available under a commercially friendly license? (This is a
deeper question I'd love feedback on)
a. I see people moving away from Fortran and more towards C++.
(Sorry no empirical data to back this, but how do we stop this trend)
b. People are trying to write books on F2K3, but what compiler can
they even base their book on?
c. Would there be any positive impact if every major vendor had the
same front-end as gfortran and implemented the latest standard? (or even
worse sent patches)
d. Would there be any negative impact to gfortran if PGI/Intel took
the front-end? (Or even worse PathScale *gasp*)
Not all commercial companies are bad (Redhat, Canonical.. etc). From my
perspective it's commercial companies that generally pay people to work
full time and get real engineering in open source done.
I could go on, but it's not productive..
If you have concerns about PathScale email me privately. My intention
is to vet the codebase. Vetting g95 is relatively easy, but there's a
chasm between it and gfortran I'm trying to map. If that's successful
I'd like to figure out if/how PathScale can contribute. if we continue
to get much more negatively this early on (I don't care the reason).
I'll just forget the whole thing.