[os-infrastructure] The infrastructure

[Joe Abbate]

Hi Andrew,

Andrew Ross wrote:
> Now we have a place where they can download code. We've automated
> setting up an dbms instance to make it one command. We've done work to
> make the tests run on any machine rather than just our internal
> machines. We have a public bug tracker, code browser, list of projects
> posted, etc. We're working on ensuring our code builds on major
> community platforms such as Fedora, Ubuntu, MacOS, etc. All of this is
> work that needed to be done independent of what our policy becomes. Do
> you agree?
>   

It is unclear to me whether it *had to be done* or it *had to be done 
right now*, particularly as I have yet to see any clear pronouncement 
from senior management as to what they envision Ingres' role in the open 
source and free software world is to be (it may have been expressed or 
even be written somewhere, but in that case it has failed to register in 
people's minds, or we wouldn't be having these arguments back and forth).

The only directives I have seen, expressed in this list, are "spend 10% 
of your time in community work" and "engineer in the open."

IMHO, Ingres Corporation is somewhat atypical of open source companies.  
If you look at say the top 30 projects by stack popularity at 
http://www.ohloh.net/projects, you'll find maybe only a couple that are 
directly controlled by a for-profit company.  Most projects are 
"staffed" by individuals working on their own free time, on the time of 
non-profit foundations (created explicitly by the projects), or on 
sponsoring-company time.  The latter is when a for-profit company tells 
an employee he or she can spend a substantial amount of company-paid 
time (30% or more) on the FOSS project.  Usually, the sponsoring company 
provides services related to the project software so allowing that work 
on company time is in lieu of contributing funds to the foundation or 
project organization.  However, the companies typically do not 
simultaneously "sell" the software under a license that forbids the 
client to "modify or create derivative works" or "reverse-engineer ... 
or attempt to derive the source code".  IMO, this requires walking a 
fine line and I hesitate to make assumptions as to what senior 
management would like to see happen or how soon it should happen.

Personally, I have long advocated that we should commit to Subversion 
and Trac, and more recently that we move to autoconf/automake instead of 
Jam (and now I'm biased towards Mercurial), but I have also realized 
that these changes could be quite disruptive.  I've also advocated that 
Ingres code be Standard C compliant (e.g., use prototypes and proper 
header inclusion everywhere), but I realize that even a small change 
like doing away with our own definition of NULL takes time and 
consensus, not because people think it's bad, but because of the impact 
on live codelines.

Take for example the bug tracker, which you scored as a D- for being 
mostly private (presumably referring to Bugs).  Originally, as some have 
pointed out, we used to have Bugs, Calltrack and a client front-end 
called Advisor.  At CA, we had to endure Startrak (in 3270 terminals or 
emulators) and later Service Desk, but we kept Bugs.  We now have 
Service Desk (which AFAIK can be used by non-paying customers), the 
internal Bugs, and Trac at bugs.ingres.com, and because of the latter 
you think we now rate as a B.  That may be OK from the standpoint of the 
"community", but from a process viewpoint, we now have three different 
issue and defect trackers which are not tied together.  Whenever a 
customer (paying or otherwise) or QA raises an issue in SD, and we 
determine it's a bug, we have to open a bug in Bugs and indicate the 
issue number.  Then when we submit a fix through Piccolo, fortunately 
there's an automated process that marks the bug as SUBM in Bugs, but (if 
we want to keep our sanity) most of us have to update the SD issue with 
the bug number and change number.  With a third system in the picture 
(Trac), which is a combination of issue tracker and defect tracker, what 
are we supposed to?  Some may argue that it's OK that community 
issues/defects be kept separate from paid customer defects/issues, but 
when someone looks for a problem, they would have to search in at least 
two places.

Joe