(j3.2006) [Re: Spreadsheet from meeting 167]

[Van Snyder]

Keith Bierman wrote:
> Sometimes the bucket is just too full. Van's point nets out to "when 
> can we get a bigger bucket" and the counter may well be "there is no 
> bigger bucket".

Although I believe we need a bigger bucket, that was not the primary 
reason for my recent message.  My point was "when can we get a bucket, 
and how will we know what to put in it?"

In 2004-2005, we had a fair and organized process to consider new 
proposals. There were announcements in comp.lang.fortran and the 
comp-Fortran-90 mailing list of opportunities to propose new features.  
Walt set up a web site to accept public proposals.  Every proposal was 
presented in a separate paper.  Plenary acted as JOR.  Every proposal 
got a fair hearing before plenary.  Everybody saw every proposal.  There 
was no subgroup veto.

Nothing like that happened at 199.  Without any announcement of an 
opportunity to present proposals for new work, Dan put a paper (12-183) 
on the server on Monday.  I hastily prepared a paper (12-195) of small 
items.  Five revisions of  12-183 were discussed in plenary.  12-195 was 
delegated to /data.  Malcolm arrived at subgroup with decisions written 
in his printed copy of 12-195, and did not budge on any of them.  Nobody 
outside subgroup pondered the ones Malcolm vetoed in subgroup, or heard 
the reasons that my colleagues want them.  The remaining small fraction 
of proposals from 12-195 were incorporated into 12-183r5.

We started to gather requirements for Fortran 2008 immediately after the 
2003 FCD ballot.  We have not considered any proposals for the next 
standard, and it has been four years since the 2008 FCD ballot.  Yet, 
somehow, I'm the one advocating to delay the next standard because I 
have a responsibility to my sponsors to advocate for the features they want.

I suppose we could incorporate the corrigenda and the accumulated typos 
and send the result to ISO as a "new" standard, and then start on a real 
revision, using a real process.

On the subject of a bigger bucket, my sponsors prefer to wait for a 
well-defined larger bucket to be filled, and to plan for the eventual 
use of its specified contents, rather than to wonder what, if anything, 
will ever be in a smaller bucket.  They have very real and measured 
labor and reliability costs that are not being addressed.  Were they to 
be addressed in a standard, even a slowly implemented one, it would 
improve the accuracy of their budget projections, which is very 
important when JPL advocates projects to NASA, or NASA advocates 
projects to Congress.  It is very difficult to plan around an empty 
bucket, and difficult to make excuses why known problems persist.

On the subject of filling a bigger bucket, my colleagues and their 
immediate sponsors have tried several times to get funding to contract 
with vendors to support development of features we felt would be 
especially advantageous.  Every time, along the way, a bean counter who 
doesn't know which end of the software to plug into the wall and which 
end to use to melt solder has vetoed the funding request.  I think this 
is a common problem in engineering and scientific organizations, even 
where software development consumes 75% of the budget.  There is a 
perception that other engineers need precision power tools, but software 
engineers can get along just fine with a hammer, a vise, and a file.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20121107/2ebe3327/attachment-0001.html