[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Migrating Subversion issues to ...

From: Branko Čibej <brane_at_apache.org>
Date: Wed, 16 Sep 2015 02:19:47 +0200

On 15.09.2015 23:31, Daniel Shahaf wrote:
> Julian Foad wrote on Tue, Sep 15, 2015 at 14:23:53 +0200:
>> First, I'd like to say I'd be happy with either of these options, and
>> I think making a conversion to one of these at the ASF is much better
>> than not doing anything.
> Agreed.
>>>> [ ] Keep our issues on Tigris
>>>> [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>>>> [ ] Migrate to the standard ASF Jira installation
>> I'd like to know, if anybody can answer this briefly, what would we
>> lose, and what would we gain, with each option? I can think of a few
>> differences (and commonalities):
> Thanks for writing this clear summary of the situation.
> I'd vote for bugzilla: it is simpler than jira (both feature-wise and
> UI-wise) but more than equal to our needs.

Perhaps. I have a deep-seated hate for Bugzilla from days past when I
had to maintain instances of that. I always ended up having to mess with
the code to get reasonable workflows and such ... and "mess" is a good
description of what I found there.

That doesn't have much bearing on what it's like to use today, of
course. Just a gut feeling.

> As to "format all descriptions as <pre>" in jira: honestly, it feels
> like a round peg in a square hole. Jira is designed around ajax and and
> html; I'd be concerned that future releases of jira might break the
> renderer plugin Ivan is planning to write — and if that happens, infra
> might simply disable the plugin until we fix it, since we'd be the only
> project affected.

An open-source plug-in of that sort probably stands a pretty good chance
of being maintained by interested parties. Especially if it's relatively

> I think both candidates have the features we use (issue number, title,
> comments, milestone). The primary consideration is which one will be
> the most frictionless going forward (both for new issues and for
> accessing old issues).

At the end of the day, I'd trust whoever puts in the cycles to make the
transition happen to select the tool they prefer. If Ivan is happy with
Jira and already has some tooling around that, I see no reason to
second-guess his choice.

I'm not happy with the closed-source nature of Jira; but then: there are
not so many open-source alternatives available at short notice.

-- Brane

>> * In both cases (a new Bugzilla instance, or Jira):
>> - We'd migrate to ASF infrastructure, and so have some reassurance
>> that it will be preserved into the future.
>> - We'd keep the existing issue numbers.
>> - All recorded URL links to issues on the old Tigris Issuezilla, in
>> mailing list archives etc., would still point there, and eventually
>> die when we turn it off (later in the future)
>> - We can probably automatically rewrite all URL links in the issues
>> themselves, and in log messages.
>> * [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>> - We'd still be using open-source software.
>> - I guess we could preserve nearly all the issue tracker content
>> exactly, including text formatting and attachments and all or most
>> fields. (What would we lose, if anyting?)
>> - Could be a good stepping stone: convert to this first, probably an
>> almost exact conversion, and then still have the option to convert to
>> Jira (or another) later.
>> * [ ] Migrate to the standard ASF Jira installation
>> - Not open-source, but more open-source-friendly than some, and
>> widely used, including at ASF.
>> - I guess we could preserve nearly all the issue tracker content,
>> but not exactly. Text formatting -- we have a couple of options.
>> Attachments -- presumably yes, but maybe handled a bit differently?
>> Fields -- I suppose these would be handled a bit differently in Jira.
>> (Can we say more about what would work differently?)
>> - Julian
Received on 2015-09-16 04:06:33 CEST

This is an archived mail posted to the Subversion Dev mailing list.