[os-infrastructure] State of the onion

Michael E. Touloumtzis Michael.Touloumtzis at ingres.com
Thu Jun 5 21:05:52 PDT 2008


Andrew, your email is timely and much needed to move things along. Thanks.

<on high horse>
We all agreed in principle at the DR summit to be a "real" open source  
company. I think this is essential to the success of Ingres-the-product  
and hence to the success of Ingres-the-corporation. Lately things have  
seemed to bog down in details and because of lack of ownership of specific  
tasks. The post-summit debate re tools was essential, but IMHO it is time  
to make reasonable decisions based on that discussion and the state of the  
available tools and move on to implementation. And business as usual is  
not an option.
</on high horse>

On Thu, 05 Jun 2008 15:25:19 -0400, Andrew Ross wrote [in part]:
> 1) p & svn
>
> I believe it's clear we have consensus that we'll run p & svn at least
> for the rest of 2008. If you object, please speak up either on the list
> or in private to me and I'll relay anonymously.

Being unaware of this mail list until about a week ago I caught up via the  
archive with a mixture of frustration and resignation. I see a mixed  
subversion/piccolo environment as inevitable for now. I would like the svn  
side to be run so that (1) casual contributors, (2) early Ingres employee  
adopters [I volunteer], and (3) Karl, can all use this tool. Either a  
fully functional open source infrastructure is essential to Ingres Corp or  
it is not; I think that it is. If it is essential, we need to implement it  
now; not later. I volunteer to help, though I'd need guidance from piccolo  
gurus like Steve. To say that we need to stick with p because svn is  
missing x y or z is like saying we'll stick with an internal phone system  
and just talk to ourselves because we love the phone system features,  
rather than speaking to the outside world with the systems that are  
available and that the rest of the world uses.

> 2) Platform support
>
> We badly need to get the major community platforms working. The
> following people have volunteered (thank you!) to take the lead to
> ensure the following platforms are working reliably and well documented
> out of svn.
>
> Mike T - Ubuntu
>
> Daryl M - MacOS
>
> Steve B - SUSE
>
> Viktoriya D - Windows
> (King can help)

I disagree with Andrew re svn/p sync and platform support relative  
priorities, feeling that the former is more important and in some ways a  
requirement for the second goal. I fix the Ubuntu build but don't have a  
way to get it from svn into piccolo main right away?? But I've agreed to  
disagree and will make platform support a priority. For Ubuntu, at least,  
the build issues are trivial to fix, anyway.

These platform ports have to be on a "clean" box - with a vanilla install.  
Once extra build tools or packages for Xerces etc. (let alone testenv  
users and such) are added to a machine, then we can no longer mimic the  
non-Ingres user experience. I have no spare box for this, so will install  
a scavenged 40GB drive for a new Ubuntu 8.04 installation. This will do  
for 32-bit. It would be very useful for those in the vanguard of platform  
support for the community builds to have "extra" hardware. I know I can  
buy a 32-bit 1-CPU build box for about US$100 and I suppose Ingres Corp  
can free up such a scratch box for OS installs and quick svn pulls and  
builds. Even more useful (as I already have some 32-bit hardware that I  
can dual-boot) would be a 64-bit machine. [Steve, any prospect of my  
getting a lower-end castoff of this sort?]

I wrote the original INSTALL document that describes the build process for  
the community version of Ingres. Imperfect at its birth (during the rush  
to go OS while we were at CA) it is now quite dated and inaccurate. I  
volunteer to fix it up.

The "just push this button" wrapper script to automatically build, test,  
etc. is something that I abhor. Yes, it is an efficiency when the process  
has been fully ironed out for a platform, for things like repetitive  
nightly builds. But it obscures what is going on and frustrates research  
to solve problems. The current build process is well engineered and can  
easily be explained to anyone who understands config and make concepts. We  
don't need to use config and make, IMHO. If folks can't extrapolate from  
their skill base to slightly different tools, then they need to seek work  
in another field. Our less than open source management (as things stand),  
our fragmented discussion forums, our broken builds for major platforms,  
and our instinct to talk to ourselves and not to talk openly to the world  
at large (customers and community) are big problems; the Jam tool is not a  
big problem.

As a tech writer in another life I know I can clean up our build procedure  
descriptions for the benefit of the community. And I'll even help to clean  
up the "just push this button" scripts. ;)

> We'll hold the code in svn fairly static for a week or two until we can
> get these platforms working well. After that, we'll start syncing (see
> #3).

I agreed to disagree, so I guess I agree.

> 3) Syncing between p & svn
>
> Looking for volunteers to help take this on. It feels like a week or
> two's work for the right people.
>
> J was thinking about helping out here, but could probably use a hand.

I care about this. For the setup I am no expert re svn/p mirroring and  
retaining history, etc. But we need ongoing work to keep things in sync,  
and it requires care and product knowledge. Again, I volunteer.

...

> 7) Merging improvements
>
> Looking for volunteers who want to work towards the best merging tools
> we can get. CALL FOR VOLUNTEERS

I volunteer to be an early svn adopter, including working through merging  
issues and such.

> 8) Community build downloads
>
> We'd like to do nightly builds from svn and make the output available
> for download. CALL FOR VOLUNTEERS.

Nightly builds (and tests) are a Good Thing, whether pulled from svn or  
the synced piccolo main code line. Do I understand that you are proposing  
to post binaries from these builds for download? If so, I disagree. It  
sounds to me like significant work with insignificant payback. Trust the  
source, Luke. My US$0.02.

MikeT


More information about the opensource-infrastructure mailing list