[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