[os-infrastructure] State of the onion

[Alex Hanshaw]

Hi Mike

 I understand your frustration about not being able to go all out svn.
However, to use your phone analogy, svn is missing the bits that allow
you to talk down the line. If you want to spend all day doing morse code
because that's all the open source world has available . . . .
 Not having labels is an inconvenience, we could probably manage but
would have to pull a separate build to do any updates to avoid branching
the TAG.
 The real show stopper in my opinion is svn's woeful inability to merge
to
code changes without manual intervention. No one on this list has said
they
have had a different experience. From the web it is a common criticism
of svn. With the number of cross integrations SE do (which will increase
with more frequent release schedules) we are back to the morse code
analogy.
 The long term goal should be to move to svn across the board. When svn
comes up to scratch. In the mean time we can try to enjoy the best of
both worlds. Remember svn can still be used to foster a community with
us
using piccolo for internal code lines. That's the objective. Using svn
is not an objective.

 No need to scavenge boxes for Ubuntu or buy a new PC. We have ESX
servers in Slough and Islandia. If you need a machine setup I'm sure we
can sort you out a VM on one of those boxes. Provide the spec you want
if you want this
arranged. Ubuntu is specifically listed as a machine type under the ESX
servers so we should not have any VM specific issues. I'm running all of
my
issue builds on a Suse93 VM.

 With regards to your comments about "red button to build", shift over
on that saddle, I need to get up on that horse with you. Single command
builds
are wonderful until something goes wrong and then it's a nightmare to
isolate the problem. With things always changing on a widening circle of
platforms we should not do anything to that wraps the build in a black
box.

 Posting nightly build binaries seems like a good idea to me. I know
I've often looked at opensource software and thought "What, I have to
build it, never mind" and not downloaded the source.

 Regards

 Alex
 


-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Michael E. Touloumtzis
Sent: 06 June 2008 05:06
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Subject: Re: [os-infrastructure] State of the onion

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
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure