[os-infrastructure] Bug/issue tracking (was commit messages)

Andrew Ross Andrew.Ross at ingres.com
Fri May 2 06:40:32 PDT 2008


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


More information about the opensource-infrastructure mailing list