[os-infrastructure] Bug/issue tracking (was commit messages)
Teresa L. King
Teresa.King at ingres.com
Mon May 5 07:57:15 PDT 2008
The link http://community.ingres.com/wiki/Development_Process
referenced is a WIP that Christine is working on & reflects her
understanding of the Development Process. I believe she links to SVN
simply because that is what we discussed in the VIP session is where the
Ingres source code lives. I think she linked to if from the DBMS
Projects Page.
________________________________
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Jeremy MB. Peel
Sent: Monday, May 05, 2008 3:00 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
It seems to me that there are basically two approaches being proposed:
1. Choose the best tool(s) for community development. Align our
processes
2. Align our processes for community development. Choose the best
tool(s)
I leave, as an exercise to the reader, the carrus and equus mappings :)
I suspect that we will be able to resolve at least some of the issues by
examining the development process and the environment (OSS in
particular), agree how to align these processes and derive a set of
requirements. Then move on to use the requirements to judge the
candidates including those currently in use.
What I found.
I found a Wiki topic documenting the Ingres development process at
http://community.ingres.com/wiki/Development_Process and it links to the
SVN repository.
<comment>
Unfortunately the topic is incomplete and the SEP testing link is to an
internal (closed) site. Furthermore the topic does not seem to be linked
to from http://community.ingres.com/wiki/Ingres_DBMS_Learn where the
most likely candidate link "Ingres Development Process
<http://community.ingres.com/wiki/Ingres_Development_Process> " is to a
Work In Progress kind of page. Maybe the topic I found is depreciated
without yet having a replacement?
</comment>
There is also an evaluation of the various SCM tools that are out there:
http://community.ingres.com/wiki/CM_features.
<aside>
I have added the category "OSS Infrastructure
<http://community.ingres.com/w/index.php?title=Category:OSS_Infrastructu
re> " in an attempt to make access to related pages more transparent if
not actually relational...
</aside>
The issues in developing complex software products have not been changed
all that much by the (re-)discovery of Open Source Software. New is the
need:
* to scale up
* to appeal to the community
* for web support
Clearly p is not as easy for the OSS community to pick up and run with
at once. But then neither is the development process. Despite that, our
published process documentation requires a lot less reading than the
Eclipse one:
http://www.eclipse.org/projects/dev_process/development_process.php.
Eclipse uses a combination of CVS and SVN and Bugzilla.
<aside>
Eclipse is a wishy-washy open source developer tool that in some sectors
is much more popular than Visual Studio. The Eclipse foundation releases
a major revision each summer involving many millions of lines of code.
This is a major achievement. I used the term "wishy-washy" not to
belittle Eclipse or the community, but rather to draw particular
attention to the enhanced need for fanatical dedication to quality and
sound algorithms in a DBMS engineer.
</aside>
Follow up.
I have a number of follow up questions:
* What are our processes to be in an OSS world (same as above or
different)?
* What exactly are we trying to achieve?
o To make Ingres seem easy to develop with to attract the many to
find a few?
o To find many more user friends?
* What is our intended audience?
o What, e.g., did Kai and Hugh say about using p and jam instead
of <insert_cm_name> and <insert_builder_name>?
o ...or other Ingres "newbies"?
* The bar to contribution is high now. Is there evidence that
this is a good or a bad thing?
* Do we need to take a step back from the technology argument or
is this a short term band aid?
For example, if p does happen to provide satisfactory functionality that
matches our requirements, we could create (have done actually) an easy
to use cross platform Java piccolo client. I imagine that this could be
turned into a web enabled tool if liked, for the web generation. An
enhancement would be to architect it following the Eclipse model that
would therefore be easy to 'tune'. It could also be integrated into Java
based IDEs such as Eclipse. And we would retain all the current working
practices and integration with Ingres maintaining the management data.
I think that this email is long and rambling enough for now, so if you
have been, thank you for reading,
jo
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: 04 May 2008 22:23
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
Durwin,
I am truly sorry to hear you are unimpressed and feel the approach is
akin to putting the cart ahead of the horse. For so many reasons, having
you support the project is not only important, but increases chances of
success.
Your tone suggests you feel there's a better way. Please share it
clearly so that everyone can decide if you're right. Better still, lead
by example and volunteer to work towards filling those gaps, as others
have done.
I'd also like to politely request that you state clearly, for the
record, what you do agree with so we can move forward on those items.
I've gone to great lengths to make the discussion and key items binary.
Either we have a public code access or not, public bug access or not,
public discussions or not, anonymous downloads or not, etc. If you agree
with each of these points, and you agree p & bugs were not designed to
support public/community access, then what reasonable alternative to
changing tools is there?
The executive team's job is not to tell us which tools and processes to
use as you suggest. We have been empowered and enabled to do what we
need to do to enable and support community. We've been given a clear
directive to spend at least 10% of our time on community.
This project has been visible to the executive team since day one. It
has been visible to community-minded members of the engineering team
(and those that cared to listen) for some time. It has also been visible
to the community and built with their active input since day one. Once
we come to a conclusion as a team, I have high confidence that decision
will be backed by the leadership within the company. They need something
solid from us to back before you'll get the crisp endorsement you seek.
It should be said: I know some are put off that they weren't involved
earlier. Let the record show no attempts have been made to hide the
project or exclude employees from getting involved. Quite the opposite,
in fact. Certainly, doing a VIP talk, a presentation at the summit,
announcing it in C.D.I. were good ways to communicate what was going on
and invite participation.
The results so far have been excellent with many actively contributing.
And a few objecting such as yourself Durwin which is healthy.
Andrew
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Durwin Wright
Sent: May 4, 2008 9:27 PM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
If you assume that I have agreed to anything that has been proposed you
are wrong. So far all discussions that have taken place on this email
group have left me very unimpressed. (There is a small voice in my head
that keeps screaming "Cart before the horse!")
Bodo is 100% correct. This discussion should be more about
fundamentally changing our processes and procedures than picking a new
set of tools. I simply do not believe that this will be anything other
than a painful process. If our business needs dictate that we need to
change our tools then I do not have any problem with going down this
route. What I have not seen is how changing the tools will help with
coordinating commercial and community development. What I have not seen
is our executives stating clearly and unequivocally that we are going to
move off of Piccolo, Bugs and Service Desk. What I have not seen is
buy-in from everyone who will be impacted by these proposed changes that
this will be painful, we must make these changes and it is okay that it
may impact our ability to support our existing paying customers.
Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com | Ingres | 500
Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA +1
650-587-5523 | fax: +1 650-587-5550
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: Sunday, May 04, 2008 4:58 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
Hi Bodo,
I'm not sure how the message that our test system (out of the box) has a
short list of deficiencies based on the input so far & and we have a few
options in mind that are even better contradicts the statement that we
haven't decided on the final tool lineup yet. Please help me understand
the contradiction. It may just be a clarification thing as email is
notorious for not being the best communications medium.
It sounds like we're agreeing that most of the critical functionality
will be fine with most tools we can choose. I've also suggested that the
closed source tools are not significantly better than open source tools
and so far no one has shouted me down. (so we may have consensus)
I do agree with you that our processes need to be looked at so we can
engage community more effectively.
I would like to suggest our base development processes aren't way out of
alignment. After the changes, we'll do design reviews, prototyping &
development, code inspections, etc. Much of this is well honed and will
look & feel the same even if command syntax involved is slightly
different. The big roadblock was that we simply cannot invite community
to participate because the infrastructure simply wasn't designed to
support it. The tools part of the project is aimed at addressing this.
I think the key thing you're getting at relates to release management.
In other words, how are we going to manage community and enterprise?
You've had a lot of good thoughts in this area. Similar to the approach
for tool selection, it'd be helpful if you and others suggested how this
should work. What are our options? What are the advantages &
disadvantages of each? The best options will rise to the top as we peer
review it.
Andrew
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Bodo Bergmann
Sent: May 4, 2008 11:37 AM
To: opensource-infrastructure at lists.ingres.com
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
Hi Andrew,
I got your message "the selection has not been done" at the summit,
that's why I was surprised to reaad about an "out of the box
svn/mercurial/bugzilla/jira" solution, which heavily contradicts your
statement from the summit.
Therefore I think my question is absolutely understandable.
I never said that p & bugs are the perfect tools and I am open to
replace them with something else if required.
But the main processes we are currently having are supported out of the
box (e.g. entering bugs, fixing bugs by submitting changes, tagging
releases and patches, connection of bugs and fixes).
Developing additional stuff on top of existing functionality to meet
individual needs will always be done, as requirements will change over
time - this has nothing to do with p & bugs.
I don't think that your "Given that we must change tools" premise is
right.
It should rather be "Given that we must change our processes".
We should identify our processes/requirements before deciding on the
products by comparing the required features.
By identifying the processes(workflows) I mean a "How should we work"
rather than a
"How do we currently work" approach - I believe that some major changes
in the way we do things are required, i.e. if we follow the Fedora model
of having 2 separate codelines (community, enterprise).
If the workflow just follows a distinct tool's approach, then we might
just and up in a mess, but at least we then handle the mess with a tool
that is widely accepted by the community.
Bodo.
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: Friday, May 02, 2008 10:59 PM
To: opensource-infrastructure at lists.ingres.com
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
Hi Bodo,
No, the selection has not been done. Multiple people mentioned this part
of the message I delivered at the summit couldn't be missed so you
likely caught it too.
To bring some order to the discussion and avoid talking about infinite
combinations and permutations of tools, we have shortlisted a few
options. We set up a test environment to serve as a proving ground and
allow benefits in the meantime. This has helped to focus and quickly
learn any flaws or shortcomings. This ultimately helps avoid analysis
paralysis given how many tools there are out there.
With respect Bodo, we all know the support team for one is still
developing tweaks and tools on top of piccolo and bugs. It's the same
thing in server development.
All this discussion factored. The logic still holds. Given that we must
change tools => Unless there's some perfect tool out there that a lot of
smart people aren't aware of the approach the team has been taking and
so far makes sense. That approach is to quickly find a combination that
gets us as close as possible to an ideal solution and identify any gaps
we need to fill.
Andrew
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Bodo Bergmann
Sent: May 2, 2008 4:01 PM
To: opensource-infrastructure at lists.ingres.com
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
Thanks,
"Please note that these scripts and tweaks weren't there when p & bugs
were first rolled out."
But p & bugs (& calltrack) had been heavily integrated from the start on
(at least in the early 1990s - where no WWW had been available yet), so
a lot of the stuff is working without any tweaks at all.
"It may not be as easy to do this with closed source tools. Service desk
is an example of this and we're closer to it than most closed source
tools yet our hands are tied in many regards."
Doesn't this experience with Service desk give us one reason more to
look for an OpenSource alternative for Jira? :)
"The most helpful thing everyone can do is add to the list of items we
need to work that may not be addressed out of the box with
svn/mercurial/bugzilla/jira"
Or mantis/orts/... - has the selection already been done?
I think we should identify our needs before deciding on the product.
Bodo.
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: Friday, May 02, 2008 3:41 PM
To: opensource-infrastructure at lists.ingres.com
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
Hi Bodo, All
Some or much of the following may be obvious but I'd like to state it
just in case.
With this project we're trying to make it much easier for open source
community to work with us. Fundamentally this means making the CM and
bugs systems public. Using tools that the open source community is used
to is also important. This covers a spectrum of open source tools and
closed source tools that are popular in the open source community such
as Jira.
We have consensus in the team that a single CM system and bug/issue
tracking tool is desirable. This expands the scope of the project to
replace what we have today.
Interestingly, none of the closed source tools we've looked at jumped
out as a clear winner worthy of spending the extra money. We're looking
at feature by feature and so far the closed source CM tools are not
significantly differentiated from the open source tools. Much like
paying for a web browser or web server, it may not make a lot of sense
to pay big money for CM tools as there is no competitive advantage (vs.
a sufficient open source solution).
At the moment, we have a small list of things that aren't covered with
subversion and Trac (even though trac is admittedly limited). However,
there are things we gain such as the public CM and bug interfaces which
would be much more work (in the wrong direction) to implement with
piccolo and bugs. Echoing Steve's comments, even this early in the
analysis, we can see we're close to a reasonable solution. Better, we
may have more than once choice with SVN and Mercurial.
It is inevitable that there would be tweaks, scripts, and customizations
that have arisen over time on top of p & bugs that may need to be
re-tweaked into any other system. Please note that these scripts and
tweaks weren't there when p & bugs were first rolled out.
As an example, mapping issues to bugs to code changes (via. a CLI tool
and web) is something entirely achievable. Doing these tweaks does make
sense with open source tools as we get the bottom X% (say 90%) of the
stack and training of community members for free. It may not be as easy
to do this with closed source tools. Service desk is an example of this
and we're closer to it than most closed source tools yet our hands are
tied in many regards.
The most helpful thing everyone can do is add to the list of items we
need to work that may not be addressed out of the box with
svn/mercurial/bugzilla/jira. Having this list makes it much easier to
dig in, find a good solution, and move forward.
I'll try and start a wiki page for the outstanding issues later today.
If someone wants to get it started now, that's fine too.
Thank you for your ideas and input.
Andrew
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Bodo Bergmann
Sent: May 2, 2008 3:01 PM
To: opensource-infrastructure at lists.ingres.com
Subject: RE: [os-infrastructure] Bug/issue tracking (was commit
messages)
The fact that leading OSS companies are using Jira doesn't make it Open
Source.
They are probably also using Microsoft's Visual Studio for some
development and MS-Office/Outlook on Windows, which doesn't make
Microsoft an Open Source vendor either, though Microsoft is definitely
the leader in that space.
They don't provide their source under a GPL (or other open source)
license - fact.
So, Jira is IMHO just the same as Perforce, they just have different
customers.
I didn't opt for Collabnet Enterprise, just gave it as an example for an
integrated solution - there might be others around.
I'm just opting for an integrated solution, as IMHO it is not our task
as product developers to spend a huge amount of time for integrating
different kind of products in order to get to a work environment that
fits our needs - and makes us at least as productive as we are now.
RE: Perforce:
As mentioned before - for open source projects it's free as well, so why
are Perforce costs shifted to the potential customer/partner/community
developer?
They are using it in order to contribute to an OpenSource community
project - so it's free for them as well.
BTW: What makes you think that Perforce is not as community development
friendly as svn?
I've worked with Perforce and find it very easy to use, extendable and
customizable (important for scripting).
I.e. I can easily add fields to it, so I can easily connect bug/issue
numbers with a change.
As the discussion has shown, this is not possible in Subversion - you
have to program around it.
I can't speak of mercurial as I haven't used it.
Anyway, I don't opt for Perforce either - I'm perfectly fine with
Subversion (or Mercurial or whatever), but if the task of integrating it
with other products means spending huge amount of time (means $$$), then
the additional price tag for Perforce, which we'd had to pay for our
continuing internal non-opensource development only, might be worth it.
You asked: "how much do you think we've spent in going as far as we have
with subversion?"
My answer: This depends on how much time Andrew and his team spend on it
- Andrew is paid by Ingres Corp. for it, and I'm sure he got a budget
for the interns, etc. - so, just because Subversion is free doesn't mean
it didn't cost anything.
I can absolutely accept to go for Subversion (or another OSS SCM)
because it's the will of the company to go with Open Source products.
But then we shouldn't stop there and look for real OSS alternatives for
the other tools as well.
Regards,
Bodo.
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Michael Sale
Sent: Friday, May 02, 2008 2:05 PM
To: opensource-infrastructure at lists.ingres.com
Subject: Re: [os-infrastructure] Bug/issue tracking (was commit
messages)
Perforce and Jira are TOTALLY different animals.
Jira is definitely the leader in this space with customers like Apache,
rPath, Jboss. Check out
http://www.atlassian.com/software/jira/customers.jsp
if you really believe it is not an OSS leader.
Re: Subversion -- On the PM side, we've looked at Collabnet Enterprise
and spoken to partners that do use it (e.g. JasperSoft) and it remains
an option. It lacks functionality and flexibility as a complete
solution, but even having enterprise hosting of subversion (one of their
services) MAY be an option. The ticketing/bug system is unable to get
mildly close to meeting the requirements I've seen coming across this
list.
At this stage, the point is to flesh out the right technology that can
meet the business requirements of BOTH supporting development of a
highly complex products set, and making that experience friendly and as
seamless as possible to the community (including our paying customers
and dealing with security bugs and data privacy laws).
The issue here is less cost at this scale (how much do you think we've
spent in going as far as we have with subversion?) and more about how we
make it that seamless and user friendly experience for the partner and
development community. I don't think perforce is totally out of the
picture IMHO, but it is definitely NOT as user friendly or community
development friendly as svn or mercurial. In this case, the scale of the
economy (Perforce costs) are shifted to the potential
customer/partner/community developer with client-based pricing. This
just doesn't scale out to encourage adding more contributors, in fact,
it does exactly the opposite. This and other reasons are why Perforce is
likely one of the less the optimal solutions. With that said, I would
like to throw out there that we SHOULD look at Perforce in this process
and that someone should step up to the plate like Andrew has done with
svn, or like Jay has done with mercurial to champion it (not me, I'm a
mercurial fan).
Regards,
Mike Sale
On May 2, 2008, at 5:42 AM, Bodo Bergmann wrote:
>
> There is a price tag for JIRA as well ($4,800 upfront + $2,400/year).
> They have an option for free use for pure Open Source projects, but
> Perforce has this too, and our sources are not all Open Source either
> (Gateways, OpenROAD, Ingres2.6).
>
> If we plan to spend some money anyway, then we should rather have a
> look at some integrated solutions e.g. CollabNet Enterprise Edition
> (which includes Subversion) http://www.collab.net/products/cee/
> This would free us from spending a lot of time with integrating
> solutions from different vendors.
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com
> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf
> Of Grant Croker
> Sent: Friday, May 02, 2008 1:19 PM
> To: opensource-infrastructure at lists.ingres.com
> Subject: Re: [os-infrastructure] Bug/issue tracking (was commit
> messages)
>
> Bodo,
>
> In principle I agree but what it should come down to is the best tool
> for the job, open-source solutions should be considered/evaluated
> along side their closed source counterparts.
>
> If the SCM is Perforce then so be it, however the $200 price tag for
> every user might count against it. If you are aware of any open source
> bug/issue tracking software that be setup to support a paying/non-
> paying
>
> customer base then let the list know.
>
> regards
>
> grant
>
> On 02/05/08 12:30, Bodo Bergmann wrote:
>> JIRA is not Open Source.
>>
>> I thought Subversion was selected because of it's the most common
>> Open
>
>> Source SCM,
>> otherwise we could also have selected Perforce - which is much more
>> Piccolo-like - due to its history/developers, so changing our
>> processes using Perforce would a much easier task to
> do.
>>
>> One of the arguments for Subversion was: It shows our commitment to
>> Open Source.
>> If that is the case, we should continue this way when planning
>> systems
>
>> for issue & bug tracking.
>>
>> Bodo.
>>
>>
>
------------------------------------------------------------------------
>> *From:* opensource-infrastructure-bounces at lists.ingres.com
>> [mailto:opensource-infrastructure-bounces at lists.ingres.com] *On
>> Behalf
>
>> Of *Alex Hanshaw
>> *Sent:* Friday, May 02, 2008 11:20 AM
>> *To:* opensource-infrastructure at lists.ingres.com
>> *Subject:* Re: [os-infrastructure] Bug/issue tracking (was commit
>> messages)
>>
>> I can see that it would be nice to be able to say we had JIRA running
>> on Ingres, but I do not see this as important.
>> Outlook does not use Ingres as a repository but we use Outlook. RPM
>> does not use Ingres as a repository but that doesn't stop us using
>> RPM based distributions of Linux.
>>
>> Alex
>>
>> On Fri, 2008-05-02 at 11:03 +0200, Grant Croker wrote:
>>> On 01/05/08 10:18, Andrew Ross wrote:
>>>> The only issue I see is that Jira does not run on Ingres currently.
> I personally feel this is important. I don't think they would do a
> port just because. If we engage and show value/share some of the work,
> they may be interested in talking.
>>> I never thought I would say this but I do not believe that not
>>> having
>
>>> Jira or whatever running on Ingres from day 1 is a problem. However
> the
>>> rollout of any system should include the plans/steps to port said
> system
>>> to Ingres. I guess this would be dependant on how willing Altassian
> (or
>>> whoever) would be to work with us to do a port and how much work
> would
>>> be involved. If there is functionality missing in Ingres that is
>>> required, how long would we be prepared to wait?
>>>
>>> g
>>>
>>>
>>
>>
>> Alex Hanshaw
>> Manager, Sustaining Engineering
>>
>> *Ingres Corporation*
>>
>> _Alex.Hanshaw at ingres.com <mailto:first.last at ingres.com>_
>> *PHONE*+44 1753 559515
>> *FAX*+44 1753 559550
>>
>> *_www.ingres.com <http://www.ingres.com/>_*
>>
>> This transmission is confidential and intended solely for the use of
>> the recipient named above. It may contain confidential, proprietary,
>> or legally privileged information. If you are not the intended
>> recipient, you are hereby notified that any unauthorized review, use,
>> disclosure or distribution is strictly prohibited. If you have
>> received this transmission in error, please contact the sender by
>> reply e-mail and delete the original transmission and all copies from
>> your system.
>>
>>
>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> opensource-infrastructure mailing list
>> opensource-infrastructure at lists.ingres.com
>> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>>
>
>
> --
> Grant Croker - Ingres PHP, Ruby and Python maintainer Here the man in
> blue crimplene accosted us once more but we patiently explained to him
> that he could **** off.
>
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/opensource-infrastructure/attachments/20080505/324b7b1a/attachment-0001.html
More information about the opensource-infrastructure
mailing list