You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2015/09/15 11:59:19 UTC
Migrating Subversion issues to ...
Hi All,
Here at the hackathon in Berlin we are discussing issue trackers, and more
particular how we should eventually move our issues to ASF infrastructure.
An old TODO.
Ivan just converted the data of the much smaller Serf issuetracker to Jira
for the Apache Serf project, and he offers to perform the migration for
Subversion too.
I think we really have 3 options:
[ ] Keep our issues on Tigris
[ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
[ ] Migrate to the standard ASF Jira installation
In Jira we can keep our existing issuenumbers, while for Bugzilla we would
need a separate instance.
Personally I would choose the third option if we aim to keep as much history
as possible (including ascii art and attachments) available after the
migration. The information in our issue database is just too valuable to
lose.. Even if it will take a few more years to get there.
Bert
Re: Migrating Subversion issues to ...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Fuhrmann wrote on Tue, Sep 15, 2015 at 12:35:15 +0200:
> On Tue, Sep 15, 2015 at 11:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
> > I think we really have 3 options:
> >
> > [ ] Keep our issues on Tigris
> >
> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
> >
> > [ ] Migrate to the standard ASF Jira installation
> >
> >
> >
> > In Jira we can keep our existing issuenumbers, while for Bugzilla we would
> > need a separate instance.
> >
>
> Keeping the issue numbers seems very important to me.
> So, +1 on option 3 and -0 on option 2.
To be clear, we could keep issue numbers with bugzilla too; we'd simply
need a separate bugzilla instance. This is precedented: spamassassin
and openoffice both have (or had) separate bugzilla instances.
Re: Migrating Subversion issues to ...
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Sep 15, 2015 at 11:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Hi All,
>
>
>
> Here at the hackathon in Berlin we are discussing issue trackers, and more
> particular how we should eventually move our issues to ASF infrastructure.
> An old TODO.
>
As much as I'm hesitant about changing project setups,
I'm +1 on moving in this case.
> Ivan just converted the data of the much smaller Serf issuetracker to Jira
> for the Apache Serf project, and he offers to perform the migration for
> Subversion too.
>
>
>
>
>
> I think we really have 3 options:
>
> [ ] Keep our issues on Tigris
>
> [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>
> [ ] Migrate to the standard ASF Jira installation
>
>
>
> In Jira we can keep our existing issuenumbers, while for Bugzilla we would
> need a separate instance.
>
Keeping the issue numbers seems very important to me.
So, +1 on option 3 and -0 on option 2.
-- Stefan^2.
Re: Migrating Subversion issues to ...
Posted by "C. Michael Pilato" <cm...@collab.net>.
Migration off of Tigris.org and onto ASF Jira seems the smartest option for
this project. +1
On Tue, Sep 15, 2015 at 5:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Hi All,
>
>
>
> Here at the hackathon in Berlin we are discussing issue trackers, and more
> particular how we should eventually move our issues to ASF infrastructure.
> An old TODO.
>
>
>
> Ivan just converted the data of the much smaller Serf issuetracker to Jira
> for the Apache Serf project, and he offers to perform the migration for
> Subversion too.
>
>
>
>
>
> I think we really have 3 options:
>
> [ ] Keep our issues on Tigris
>
> [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>
> [ ] Migrate to the standard ASF Jira installation
>
>
>
> In Jira we can keep our existing issuenumbers, while for Bugzilla we would
> need a separate instance.
>
>
>
> Personally I would choose the third option if we aim to keep as much
> history as possible (including ascii art and attachments) available after
> the migration. The information in our issue database is just too valuable
> to lose…. Even if it will take a few more years to get there.
>
>
>
> Bert
>
Re: Migrating Subversion issues to ...
Posted by Stefan Hett <st...@egosoft.com>.
On 9/15/2015 1:37 PM, Greg Stein wrote:
> On Tue, Sep 15, 2015 at 6:34 AM, Stefan Hett <stefan@egosoft.com
> <ma...@egosoft.com>> wrote:
>
> On 9/15/2015 12:49 PM, Greg Stein wrote:
>> On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <ivan@visualsvn.com
>> <ma...@visualsvn.com>> wrote:
>>
>> On 15 September 2015 at 11:59, Bert Huijben <bert@qqmail.nl
>> <ma...@qqmail.nl>> wrote:
>>
>> >...
>>
>> > I think we really have 3 options:
>> >
>> > [ ] Keep our issues on Tigris
>> > [ ] Migrate our issues to a new Bugzilla instance hosted by
>> ASF infra
>> > [ ] Migrate to the standard ASF Jira installation
>>
>>
>> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>>
>> >...
>>
>> One option to resolve this would be create JIRA plugin with very
>> simple "field renderer" that uses monospaced font. Field
>> renderer is
>> configured per project, so it's technically possible to use it on
>> shared ASF JIRA installation. The only question is whether
>> ASF infra
>> allow us to install such simple plugin (or develop it for us?).
>>
>>
>> They already have lots of concerns around the JIRA installation.
>> I seriously doubt they'd approve any such plugin, and certainly
>> would not develop/test such a thing. I'll go ask ...
>>
>> Do JIRA comments have any sort of formatting available (eg
>> markdown), to do the formatting?
> Short answer: yes it has
> From JIRA's feature point of view, it has the same features
> available as the description field or any other custom field you
> add. That said, it can be set to use the text- or the wiki-markup
> renderer.
>
>
> Yup. I just found the following page:
>
> https://confluence.atlassian.com/jira/configuring-renderers-185729478.html
>
> I don't see "Steps to Reproduce" in there, but we won't be converting
> any Tigris issues into that field. We don't need monospace there. ...
> as long as we have monospace in Description and Comments, then we're
> good to go.
JIRA doesn't specify a "Steps to Reproduce" field out of the box.
However, nothing prevents you (as an admin) to add such a custom field.
--
Regards,
Stefan Hett
Re: Migrating Subversion issues to ...
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 15, 2015 at 06:51:52AM -0500, Greg Stein wrote:
> Gavin set up a test/example: https://issues.apache.org/jira/browse/TST-210
That's good enough for me. Thanks!
Re: Migrating Subversion issues to ...
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 15, 2015 at 02:22:41PM +0200, Ivan Zhakov wrote:
> The problem that {noformat} tag adds scrollbars. See the following
> comment as an example:
> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14745334&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14745334
Can we ask INFRA to remove one line from the style sheet for us?
div.preformattedContent pre, div.codeContent pre {
max-height: 30em; <--- remove this line
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 15 September 2015 at 13:51, Greg Stein <gs...@gmail.com> wrote:
> On Tue, Sep 15, 2015 at 6:37 AM, Greg Stein <gs...@gmail.com> wrote:
>>
>> On Tue, Sep 15, 2015 at 6:34 AM, Stefan Hett <st...@egosoft.com> wrote:
>>>
>>> On 9/15/2015 12:49 PM, Greg Stein wrote:
>>>
>>> On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>
>>>> On 15 September 2015 at 11:59, Bert Huijben <be...@qqmail.nl> wrote:
>>>
>>> >...
>>>>
>>>> > I think we really have 3 options:
>>>> >
>>>> > [ ] Keep our issues on Tigris
>>>> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>>>> > [ ] Migrate to the standard ASF Jira installation
>>>
>>>
>>> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>>>
>>> >...
>>>>
>>>> One option to resolve this would be create JIRA plugin with very
>>>> simple "field renderer" that uses monospaced font. Field renderer is
>>>> configured per project, so it's technically possible to use it on
>>>> shared ASF JIRA installation. The only question is whether ASF infra
>>>> allow us to install such simple plugin (or develop it for us?).
>>>
>>>
>>> They already have lots of concerns around the JIRA installation. I
>>> seriously doubt they'd approve any such plugin, and certainly would not
>>> develop/test such a thing. I'll go ask ...
>>>
>>> Do JIRA comments have any sort of formatting available (eg markdown), to
>>> do the formatting?
>>>
>>> Short answer: yes it has
>>> From JIRA's feature point of view, it has the same features available as
>>> the description field or any other custom field you add. That said, it can
>>> be set to use the text- or the wiki-markup renderer.
>>
>>
>> Yup. I just found the following page:
>>
>> https://confluence.atlassian.com/jira/configuring-renderers-185729478.html
>>
>> I don't see "Steps to Reproduce" in there, but we won't be converting any
>> Tigris issues into that field. We don't need monospace there. ... as long as
>> we have monospace in Description and Comments, then we're good to go.
>>
>> I'd further posit: we can lose some fidelity in the conversion. The above
>> seems like we'll get 99%
>
>
> Gavin set up a test/example: https://issues.apache.org/jira/browse/TST-210
>
The problem that {noformat} tag adds scrollbars. See the following
comment as an example:
https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14745334&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14745334
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Sep 15, 2015 at 6:37 AM, Greg Stein <gs...@gmail.com> wrote:
> On Tue, Sep 15, 2015 at 6:34 AM, Stefan Hett <st...@egosoft.com> wrote:
>
>> On 9/15/2015 12:49 PM, Greg Stein wrote:
>>
>> On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>>> On 15 September 2015 at 11:59, Bert Huijben < <be...@qqmail.nl>
>>> bert@qqmail.nl> wrote:
>>>
>> >...
>>
>>> > I think we really have 3 options:
>>> >
>>> > [ ] Keep our issues on Tigris
>>> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>>> > [ ] Migrate to the standard ASF Jira installation
>>>
>>
>> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>>
>> >...
>>
>>> One option to resolve this would be create JIRA plugin with very
>>> simple "field renderer" that uses monospaced font. Field renderer is
>>> configured per project, so it's technically possible to use it on
>>> shared ASF JIRA installation. The only question is whether ASF infra
>>> allow us to install such simple plugin (or develop it for us?).
>>>
>>
>> They already have lots of concerns around the JIRA installation. I
>> seriously doubt they'd approve any such plugin, and certainly would not
>> develop/test such a thing. I'll go ask ...
>>
>> Do JIRA comments have any sort of formatting available (eg markdown), to
>> do the formatting?
>>
>> Short answer: yes it has
>> From JIRA's feature point of view, it has the same features available as
>> the description field or any other custom field you add. That said, it can
>> be set to use the text- or the wiki-markup renderer.
>>
>
> Yup. I just found the following page:
>
> https://confluence.atlassian.com/jira/configuring-renderers-185729478.html
>
> I don't see "Steps to Reproduce" in there, but we won't be converting any
> Tigris issues into that field. We don't need monospace there. ... as long
> as we have monospace in Description and Comments, then we're good to go.
>
> I'd further posit: we can lose some fidelity in the conversion. The above
> seems like we'll get 99%
>
Gavin set up a test/example: https://issues.apache.org/jira/browse/TST-210
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Sep 15, 2015 at 6:34 AM, Stefan Hett <st...@egosoft.com> wrote:
> On 9/15/2015 12:49 PM, Greg Stein wrote:
>
> On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
>> On 15 September 2015 at 11:59, Bert Huijben < <be...@qqmail.nl>
>> bert@qqmail.nl> wrote:
>>
> >...
>
>> > I think we really have 3 options:
>> >
>> > [ ] Keep our issues on Tigris
>> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>> > [ ] Migrate to the standard ASF Jira installation
>>
>
> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>
> >...
>
>> One option to resolve this would be create JIRA plugin with very
>> simple "field renderer" that uses monospaced font. Field renderer is
>> configured per project, so it's technically possible to use it on
>> shared ASF JIRA installation. The only question is whether ASF infra
>> allow us to install such simple plugin (or develop it for us?).
>>
>
> They already have lots of concerns around the JIRA installation. I
> seriously doubt they'd approve any such plugin, and certainly would not
> develop/test such a thing. I'll go ask ...
>
> Do JIRA comments have any sort of formatting available (eg markdown), to
> do the formatting?
>
> Short answer: yes it has
> From JIRA's feature point of view, it has the same features available as
> the description field or any other custom field you add. That said, it can
> be set to use the text- or the wiki-markup renderer.
>
Yup. I just found the following page:
https://confluence.atlassian.com/jira/configuring-renderers-185729478.html
I don't see "Steps to Reproduce" in there, but we won't be converting any
Tigris issues into that field. We don't need monospace there. ... as long
as we have monospace in Description and Comments, then we're good to go.
I'd further posit: we can lose some fidelity in the conversion. The above
seems like we'll get 99%
Cheers,
-g
Re: Migrating Subversion issues to ...
Posted by Stefan Hett <st...@egosoft.com>.
On 9/15/2015 12:49 PM, Greg Stein wrote:
> On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <ivan@visualsvn.com
> <ma...@visualsvn.com>> wrote:
>
> On 15 September 2015 at 11:59, Bert Huijben <bert@qqmail.nl
> <ma...@qqmail.nl>> wrote:
>
> >...
>
> > I think we really have 3 options:
> >
> > [ ] Keep our issues on Tigris
> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF
> infra
> > [ ] Migrate to the standard ASF Jira installation
>
>
> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>
> >...
>
> One option to resolve this would be create JIRA plugin with very
> simple "field renderer" that uses monospaced font. Field renderer is
> configured per project, so it's technically possible to use it on
> shared ASF JIRA installation. The only question is whether ASF infra
> allow us to install such simple plugin (or develop it for us?).
>
>
> They already have lots of concerns around the JIRA installation. I
> seriously doubt they'd approve any such plugin, and certainly would
> not develop/test such a thing. I'll go ask ...
>
> Do JIRA comments have any sort of formatting available (eg markdown),
> to do the formatting?
Short answer: yes it has
From JIRA's feature point of view, it has the same features available
as the description field or any other custom field you add. That said,
it can be set to use the text- or the wiki-markup renderer.
--
Regards,
Stefan Hett
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 15.09.2015 14:25, Ivan Zhakov wrote:
> On 15 September 2015 at 13:33, Greg Stein <gs...@gmail.com> wrote:
>> Infra did say they might allow a plugin, but they would want to review it
>> first. Apparently, plugins affect the *entire* instance, in their experience
>> (tho, they might not be Render plugins; short answer: they are hesitant, but
>> might allow it). ... And yes: no cycles there to write such a plugin.
>>
> It would be extremely simple (just wrap content in <pre> tag) and
> open-source plugin.
It's probably not that simple, since you'd have to HTML-escape the
content first; and the default Jira style for pre-formatted text is
probably not what you want to see. But, yah, not so horribly hard, I guess.
-- Brane
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 15 September 2015 at 13:33, Greg Stein <gs...@gmail.com> wrote:
> I got some details back from ASF Infra:
>
> """
> gstein ok so if we enable wiki style formatting you can wrap anything in
> {{monospaced}} blocks. And use {code} blocks etc. This is already built in
> to Jira and just needs enabling for your project jira.
> see:
> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=advanced
> and
> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=texteffects
> for more info.
> """
>
> This sounds like the wiki formatting schabi is talking about. So I'd raise
> two questions:
>
> 1) maybe the wiki *can* somehow be applied to Description and Steps.
> how/true?
Wiki renderer can be enabled for all fields, including Description and comments.
> 2) maybe we call it "good enough", and go with proportional fonts for
> Description/Steps.
>
The real problem that wiki renderer adds vertical scroll bar for
{noformat} blocks longer than 10-20 lines.
> Infra did say they might allow a plugin, but they would want to review it
> first. Apparently, plugins affect the *entire* instance, in their experience
> (tho, they might not be Render plugins; short answer: they are hesitant, but
> might allow it). ... And yes: no cycles there to write such a plugin.
>
It would be extremely simple (just wrap content in <pre> tag) and
open-source plugin.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Stefan Hett <st...@egosoft.com>.
On 9/15/2015 1:33 PM, Greg Stein wrote:
> I got some details back from ASF Infra:
>
> """
> gstein ok so if we enable wiki style formatting you can wrap anything
> in {{monospaced}} blocks. And use {code} blocks etc. This is already
> built in to Jira and just needs enabling for your project jira.
> see:
> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=advanced and
> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=texteffects for
> more info.
> """
>
> This sounds like the wiki formatting schabi is talking about. So I'd
> raise two questions:
>
> 1) maybe the wiki *can* somehow be applied to Description and Steps.
> how/true?
Steps pointed out in this thread (answer from Pushpraj Singh):
https://answers.atlassian.com/questions/177024/how-to-get-rich-text-in-jira-comments
"Click cog icon >> Goto Issues >> Fields >> Field Configuration >>
choose your project >> Click edit renderers given with Comments and from
the drop down select "Wiki Style Renderer". This will enable rich text ,
you can attach thumbnails, URLs, bold, italic, colored text etc. etc."
--
Regards,
Stefan Hett
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
I got some details back from ASF Infra:
"""
gstein ok so if we enable wiki style formatting you can wrap anything in
{{monospaced}} blocks. And use {code} blocks etc. This is already built in
to Jira and just needs enabling for your project jira.
see:
https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=advanced
and
https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=texteffects
for
more info.
"""
This sounds like the wiki formatting schabi is talking about. So I'd raise
two questions:
1) maybe the wiki *can* somehow be applied to Description and Steps.
how/true?
2) maybe we call it "good enough", and go with proportional fonts for
Description/Steps.
Infra did say they might allow a plugin, but they would want to review it
first. Apparently, plugins affect the *entire* instance, in their
experience (tho, they might not be Render plugins; short answer: they are
hesitant, but might allow it). ... And yes: no cycles there to write such a
plugin.
Cheers,
-g
On Tue, Sep 15, 2015 at 5:54 AM, Markus Schaber <m....@codesys.com>
wrote:
> Hi,
>
>
>
> We’re running jira here in-house, and it’s a rather nice system, and the
> latest releases work actually rock solid on our server.
>
>
>
> There is some wiki syntax for preformatted text, like {code} or
> {noformat}, but (at least in our installation) it’s only available for the
> comments, but not within the Description and Steps to Repeat fields.
>
>
>
> Best regards
>
> Markus Schaber
>
> *CODESYS®* a trademark of 3S-Smart Software Solutions GmbH
>
> *Inspiring Automation Solutions *
> ------------------------------
>
> 3S-Smart Software Solutions GmbH
> Dipl.-Inf. Markus Schaber | Product Development Core Technology
> Memminger Str. 151 | 87439 Kempten | Germany
> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>
> E-Mail: m.schaber@codesys.com | Web: codesys.com <http://www.codesys.com>
> | CODESYS store: store.codesys.com
> CODESYS forum: forum.codesys.com
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915*
> * ------------------------------ *
>
>
>
> *This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.*
>
> *Von:* Greg Stein [mailto:gstein@gmail.com]
> *Gesendet:* Dienstag, 15. September 2015 12:50
> *An:* Ivan Zhakov
> *Cc:* dev@subversion.apache.org
> *Betreff:* Re: Migrating Subversion issues to ...
>
>
>
> On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
> On 15 September 2015 at 11:59, Bert Huijben <be...@qqmail.nl> wrote:
>
> >...
>
> > I think we really have 3 options:
> >
> > [ ] Keep our issues on Tigris
> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
> > [ ] Migrate to the standard ASF Jira installation
>
>
>
> +1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>
>
>
> >...
>
> One option to resolve this would be create JIRA plugin with very
> simple "field renderer" that uses monospaced font. Field renderer is
> configured per project, so it's technically possible to use it on
> shared ASF JIRA installation. The only question is whether ASF infra
> allow us to install such simple plugin (or develop it for us?).
>
>
>
> They already have lots of concerns around the JIRA installation. I
> seriously doubt they'd approve any such plugin, and certainly would not
> develop/test such a thing. I'll go ask ...
>
>
>
> Do JIRA comments have any sort of formatting available (eg markdown), to
> do the formatting?
>
>
>
> Cheers,
>
> -g
>
>
>
AW: Migrating Subversion issues to ...
Posted by Markus Schaber <m....@codesys.com>.
Hi,
We’re running jira here in-house, and it’s a rather nice system, and the latest releases work actually rock solid on our server.
There is some wiki syntax for preformatted text, like {code} or {noformat}, but (at least in our installation) it’s only available for the comments, but not within the Description and Steps to Repeat fields.
Best regards
Markus Schaber
CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
________________________________
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com<ma...@codesys.com> | Web: codesys.com<http://www.codesys.com> | CODESYS store: store.codesys.com<http://store.codesys.com>
CODESYS forum: forum.codesys.com<http://forum.codesys.com>
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Von: Greg Stein [mailto:gstein@gmail.com]
Gesendet: Dienstag, 15. September 2015 12:50
An: Ivan Zhakov
Cc: dev@subversion.apache.org
Betreff: Re: Migrating Subversion issues to ...
On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <iv...@visualsvn.com>> wrote:
On 15 September 2015 at 11:59, Bert Huijben <be...@qqmail.nl>> wrote:
>...
> I think we really have 3 options:
>
> [ ] Keep our issues on Tigris
> [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
> [ ] Migrate to the standard ASF Jira installation
+1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>...
One option to resolve this would be create JIRA plugin with very
simple "field renderer" that uses monospaced font. Field renderer is
configured per project, so it's technically possible to use it on
shared ASF JIRA installation. The only question is whether ASF infra
allow us to install such simple plugin (or develop it for us?).
They already have lots of concerns around the JIRA installation. I seriously doubt they'd approve any such plugin, and certainly would not develop/test such a thing. I'll go ask ...
Do JIRA comments have any sort of formatting available (eg markdown), to do the formatting?
Cheers,
-g
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Sep 15, 2015 at 5:12 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 15 September 2015 at 11:59, Bert Huijben <be...@qqmail.nl> wrote:
>
>...
> > I think we really have 3 options:
> >
> > [ ] Keep our issues on Tigris
> > [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
> > [ ] Migrate to the standard ASF Jira installation
>
+1 to JIRA. (and -0 on tigris; -0.5 bugzilla)
>...
> One option to resolve this would be create JIRA plugin with very
> simple "field renderer" that uses monospaced font. Field renderer is
> configured per project, so it's technically possible to use it on
> shared ASF JIRA installation. The only question is whether ASF infra
> allow us to install such simple plugin (or develop it for us?).
>
They already have lots of concerns around the JIRA installation. I
seriously doubt they'd approve any such plugin, and certainly would not
develop/test such a thing. I'll go ask ...
Do JIRA comments have any sort of formatting available (eg markdown), to do
the formatting?
Cheers,
-g
Re: Migrating Subversion issues to ...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
By the way, to be clear, this isn't supposed to block anybody from
proceeding with the jira test import. I just wanted to make the case
for bz as well.
Daniel
Daniel Shahaf wrote on Tue, Sep 15, 2015 at 21:31:37 +0000:
> 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.
>
> 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.
>
> 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).
>
> Cheers,
>
> Daniel
>
> > * 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
Re: Migrating Subversion issues to ...
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Sep 16, 2015 at 12:07 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
>>> Hi,
>>>>>
>>>>> Speaking about Ivan's suggested monospace-renderer-plugin and the concern
>>>>> that it might break with a future version of JIRA: My experience with
>>>>> JIRA
>>>>> (which dates back to around 2005 I guess) is that Atlassian is quite
>>>>> reluctant with introducing changes which break plugins. So it's quite
>>>>> rare
>>>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
>>>>> Things
>>>>> are slightly different when the major version numbers change, but then
>>>>> this
>>>>> only happens every 2 years or so. Hence the maintenance work for such a
>>>>> plugin should be considered quite low in the general case.
>>>>> On the other side Atlassian requires plugin developers to maintain and
>>>>> test
>>>>> their plugins on a regular basis (so they are still ensured to be
>>>>> compatible
>>>>> with later versions).
>>>>> If that's some concern and there is some help wanted/needed, I'd be
>>>>> willing
>>>>> to offer Ivan a hand with the maintenance work on his plugin (if that
>>>>> would
>>>>> help). As a test environment I'd provide my own JIRA instance, so that
>>>>> would
>>>>> not add much workload to me.
>>>>>
>>>> Thanks for offering help, but I already have test JIRA instance at my
>>>> office that I used for Serf project issues migration.
>>>>
>>>> Btw do you have any experience in writing JIRA plugins? Writing
>>>> monospaced (preformated) text render would be big help.
>>>
>>> Unfortunately not at all, otherwise I would have offered to do so.
>>> While I do have some decent knowledge of Java due to my studies, I haven't
>>> been coding in Java for several years now and don't even have a development
>>> environment set-up for that.
>>>
>> I also don't have Java environment, while I developed several plugins
>> more then 10 years ago.
>> Link to the Atlassian tutorial if ever want to learn it:
>> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
>>
>
> I think we're almost there: I don't think we need a custom renderer or
> plugin. Apparently, we can get what we want by enclosing everything
> coming from bugzilla within: {noformat:nopanel=true}
>
> That way, we still have the option of using the normal rendering for
> new issues (or even editing old issues to move "nicer parts" out of
> the noformat block), and only put inside a noformat block the things
> which really need to be monospaced.
>
> See here for an example:
> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>
And apparently long lines still give a horizontal scrollbar, so that
seems about perfect :-) :
https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747255&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747255
BTW, the nopanel option was mentioned here (though its documentation
is wrong / confusing):
https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=advanced
--
Johan
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 September 2015 at 12:07, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
>>> Hi,
>>>>>
>>>>> Speaking about Ivan's suggested monospace-renderer-plugin and the concern
>>>>> that it might break with a future version of JIRA: My experience with
>>>>> JIRA
>>>>> (which dates back to around 2005 I guess) is that Atlassian is quite
>>>>> reluctant with introducing changes which break plugins. So it's quite
>>>>> rare
>>>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
>>>>> Things
>>>>> are slightly different when the major version numbers change, but then
>>>>> this
>>>>> only happens every 2 years or so. Hence the maintenance work for such a
>>>>> plugin should be considered quite low in the general case.
>>>>> On the other side Atlassian requires plugin developers to maintain and
>>>>> test
>>>>> their plugins on a regular basis (so they are still ensured to be
>>>>> compatible
>>>>> with later versions).
>>>>> If that's some concern and there is some help wanted/needed, I'd be
>>>>> willing
>>>>> to offer Ivan a hand with the maintenance work on his plugin (if that
>>>>> would
>>>>> help). As a test environment I'd provide my own JIRA instance, so that
>>>>> would
>>>>> not add much workload to me.
>>>>>
>>>> Thanks for offering help, but I already have test JIRA instance at my
>>>> office that I used for Serf project issues migration.
>>>>
>>>> Btw do you have any experience in writing JIRA plugins? Writing
>>>> monospaced (preformated) text render would be big help.
>>>
>>> Unfortunately not at all, otherwise I would have offered to do so.
>>> While I do have some decent knowledge of Java due to my studies, I haven't
>>> been coding in Java for several years now and don't even have a development
>>> environment set-up for that.
>>>
>> I also don't have Java environment, while I developed several plugins
>> more then 10 years ago.
>> Link to the Atlassian tutorial if ever want to learn it:
>> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
>>
>
> I think we're almost there: I don't think we need a custom renderer or
> plugin. Apparently, we can get what we want by enclosing everything
> coming from bugzilla within: {noformat:nopanel=true}
>
> That way, we still have the option of using the normal rendering for
> new issues (or even editing old issues to move "nicer parts" out of
> the noformat block), and only put inside a noformat block the things
> which really need to be monospaced.
>
> See here for an example:
> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>
>
That's great! I'll update my conversion script to use
"{noformat:nopanel=true}" instead of "{noformat}" and ask INFRA team
use it for test conversion.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
Overall the migration looks pretty good I would agree. I was impressed to
see things like dependencies come through pretty cleanly.
The one problem I have that I assume is related to this formatting is that
it seems like line wrapping does not happen as it normally would. So
descriptions etc seem like a series of fixed-width monospaced lines. A lot
of the Jira UI seems to expect it to be a block of text that it would line
wrap as needed. Or at least I assume that is what it would look like.
So many of the normal screens you cannot really read a lot of the text
without going into full screen.
That said, I cannot remember the last time I even went into IssueZilla. So
I cannot say this will impact me at all. Whatever you guys decide is OK
with me.
Mark
On Wed, Sep 16, 2015 at 9:10 AM, Greg Stein <gs...@gmail.com> wrote:
> Well, the noformat in the test import looks just fine. It works, may as
> well leave that. ... But end the work there. I'm with Mark: having the
> issues in JIRA is *way* more important than further refinements and the
> time involved.
>
> On Wed, Sep 16, 2015 at 8:00 AM, Mark Phippard <ma...@gmail.com> wrote:
>
>> If what Johan says is all true (which I assume it is) then why not just
>> do a straight-up migration of issues and let things be proportional? You
>> could then manually correct the parts of descriptions or comments that
>> would be better be formatted differently ... but only if someone cares
>> enough.
>>
>> If it is an old closed issue, who would even care?
>>
>> Anyway, it just seems like new issues moving forward will be proportional
>> font except where people choose to change format, so why not do same for
>> history? Especially given that it seems easier.
>>
>> Mark
>>
>>
>> On Wed, Sep 16, 2015 at 6:07 AM, Johan Corveleyn <jc...@gmail.com>
>> wrote:
>>
>>> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com>
>>> wrote:
>>> > On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
>>> >> Hi,
>>> >>>>
>>> >>>> Speaking about Ivan's suggested monospace-renderer-plugin and the
>>> concern
>>> >>>> that it might break with a future version of JIRA: My experience
>>> with
>>> >>>> JIRA
>>> >>>> (which dates back to around 2005 I guess) is that Atlassian is quite
>>> >>>> reluctant with introducing changes which break plugins. So it's
>>> quite
>>> >>>> rare
>>> >>>> that that a plugin which works in 6.0 breaks during the 6.x
>>> releases.
>>> >>>> Things
>>> >>>> are slightly different when the major version numbers change, but
>>> then
>>> >>>> this
>>> >>>> only happens every 2 years or so. Hence the maintenance work for
>>> such a
>>> >>>> plugin should be considered quite low in the general case.
>>> >>>> On the other side Atlassian requires plugin developers to maintain
>>> and
>>> >>>> test
>>> >>>> their plugins on a regular basis (so they are still ensured to be
>>> >>>> compatible
>>> >>>> with later versions).
>>> >>>> If that's some concern and there is some help wanted/needed, I'd be
>>> >>>> willing
>>> >>>> to offer Ivan a hand with the maintenance work on his plugin (if
>>> that
>>> >>>> would
>>> >>>> help). As a test environment I'd provide my own JIRA instance, so
>>> that
>>> >>>> would
>>> >>>> not add much workload to me.
>>> >>>>
>>> >>> Thanks for offering help, but I already have test JIRA instance at my
>>> >>> office that I used for Serf project issues migration.
>>> >>>
>>> >>> Btw do you have any experience in writing JIRA plugins? Writing
>>> >>> monospaced (preformated) text render would be big help.
>>> >>
>>> >> Unfortunately not at all, otherwise I would have offered to do so.
>>> >> While I do have some decent knowledge of Java due to my studies, I
>>> haven't
>>> >> been coding in Java for several years now and don't even have a
>>> development
>>> >> environment set-up for that.
>>> >>
>>> > I also don't have Java environment, while I developed several plugins
>>> > more then 10 years ago.
>>> > Link to the Atlassian tutorial if ever want to learn it:
>>> >
>>> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
>>> >
>>>
>>> I think we're almost there: I don't think we need a custom renderer or
>>> plugin. Apparently, we can get what we want by enclosing everything
>>> coming from bugzilla within: {noformat:nopanel=true}
>>>
>>> That way, we still have the option of using the normal rendering for
>>> new issues (or even editing old issues to move "nicer parts" out of
>>> the noformat block), and only put inside a noformat block the things
>>> which really need to be monospaced.
>>>
>>> See here for an example:
>>>
>>> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>>>
>>>
>>>
>>> --
>>> Johan
>>>
>>
>>
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 September 2015 at 15:10, Greg Stein <gs...@gmail.com> wrote:
> Well, the noformat in the test import looks just fine. It works, may as well
> leave that. ... But end the work there. I'm with Mark: having the issues in
> JIRA is *way* more important than further refinements and the time involved.
>
I completely agree that {noformat:nopanel=true} is the best option: we
still preserve older issues while have an option to use wiki-style
markup for new issues. And we don't need custom plugins and etc.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
Well, the noformat in the test import looks just fine. It works, may as
well leave that. ... But end the work there. I'm with Mark: having the
issues in JIRA is *way* more important than further refinements and the
time involved.
On Wed, Sep 16, 2015 at 8:00 AM, Mark Phippard <ma...@gmail.com> wrote:
> If what Johan says is all true (which I assume it is) then why not just do
> a straight-up migration of issues and let things be proportional? You
> could then manually correct the parts of descriptions or comments that
> would be better be formatted differently ... but only if someone cares
> enough.
>
> If it is an old closed issue, who would even care?
>
> Anyway, it just seems like new issues moving forward will be proportional
> font except where people choose to change format, so why not do same for
> history? Especially given that it seems easier.
>
> Mark
>
>
> On Wed, Sep 16, 2015 at 6:07 AM, Johan Corveleyn <jc...@gmail.com>
> wrote:
>
>> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> > On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
>> >> Hi,
>> >>>>
>> >>>> Speaking about Ivan's suggested monospace-renderer-plugin and the
>> concern
>> >>>> that it might break with a future version of JIRA: My experience with
>> >>>> JIRA
>> >>>> (which dates back to around 2005 I guess) is that Atlassian is quite
>> >>>> reluctant with introducing changes which break plugins. So it's quite
>> >>>> rare
>> >>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
>> >>>> Things
>> >>>> are slightly different when the major version numbers change, but
>> then
>> >>>> this
>> >>>> only happens every 2 years or so. Hence the maintenance work for
>> such a
>> >>>> plugin should be considered quite low in the general case.
>> >>>> On the other side Atlassian requires plugin developers to maintain
>> and
>> >>>> test
>> >>>> their plugins on a regular basis (so they are still ensured to be
>> >>>> compatible
>> >>>> with later versions).
>> >>>> If that's some concern and there is some help wanted/needed, I'd be
>> >>>> willing
>> >>>> to offer Ivan a hand with the maintenance work on his plugin (if that
>> >>>> would
>> >>>> help). As a test environment I'd provide my own JIRA instance, so
>> that
>> >>>> would
>> >>>> not add much workload to me.
>> >>>>
>> >>> Thanks for offering help, but I already have test JIRA instance at my
>> >>> office that I used for Serf project issues migration.
>> >>>
>> >>> Btw do you have any experience in writing JIRA plugins? Writing
>> >>> monospaced (preformated) text render would be big help.
>> >>
>> >> Unfortunately not at all, otherwise I would have offered to do so.
>> >> While I do have some decent knowledge of Java due to my studies, I
>> haven't
>> >> been coding in Java for several years now and don't even have a
>> development
>> >> environment set-up for that.
>> >>
>> > I also don't have Java environment, while I developed several plugins
>> > more then 10 years ago.
>> > Link to the Atlassian tutorial if ever want to learn it:
>> >
>> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
>> >
>>
>> I think we're almost there: I don't think we need a custom renderer or
>> plugin. Apparently, we can get what we want by enclosing everything
>> coming from bugzilla within: {noformat:nopanel=true}
>>
>> That way, we still have the option of using the normal rendering for
>> new issues (or even editing old issues to move "nicer parts" out of
>> the noformat block), and only put inside a noformat block the things
>> which really need to be monospaced.
>>
>> See here for an example:
>>
>> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>>
>>
>>
>> --
>> Johan
>>
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
If what Johan says is all true (which I assume it is) then why not just do
a straight-up migration of issues and let things be proportional? You
could then manually correct the parts of descriptions or comments that
would be better be formatted differently ... but only if someone cares
enough.
If it is an old closed issue, who would even care?
Anyway, it just seems like new issues moving forward will be proportional
font except where people choose to change format, so why not do same for
history? Especially given that it seems easier.
Mark
On Wed, Sep 16, 2015 at 6:07 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> > On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
> >> Hi,
> >>>>
> >>>> Speaking about Ivan's suggested monospace-renderer-plugin and the
> concern
> >>>> that it might break with a future version of JIRA: My experience with
> >>>> JIRA
> >>>> (which dates back to around 2005 I guess) is that Atlassian is quite
> >>>> reluctant with introducing changes which break plugins. So it's quite
> >>>> rare
> >>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
> >>>> Things
> >>>> are slightly different when the major version numbers change, but then
> >>>> this
> >>>> only happens every 2 years or so. Hence the maintenance work for such
> a
> >>>> plugin should be considered quite low in the general case.
> >>>> On the other side Atlassian requires plugin developers to maintain and
> >>>> test
> >>>> their plugins on a regular basis (so they are still ensured to be
> >>>> compatible
> >>>> with later versions).
> >>>> If that's some concern and there is some help wanted/needed, I'd be
> >>>> willing
> >>>> to offer Ivan a hand with the maintenance work on his plugin (if that
> >>>> would
> >>>> help). As a test environment I'd provide my own JIRA instance, so that
> >>>> would
> >>>> not add much workload to me.
> >>>>
> >>> Thanks for offering help, but I already have test JIRA instance at my
> >>> office that I used for Serf project issues migration.
> >>>
> >>> Btw do you have any experience in writing JIRA plugins? Writing
> >>> monospaced (preformated) text render would be big help.
> >>
> >> Unfortunately not at all, otherwise I would have offered to do so.
> >> While I do have some decent knowledge of Java due to my studies, I
> haven't
> >> been coding in Java for several years now and don't even have a
> development
> >> environment set-up for that.
> >>
> > I also don't have Java environment, while I developed several plugins
> > more then 10 years ago.
> > Link to the Atlassian tutorial if ever want to learn it:
> >
> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
> >
>
> I think we're almost there: I don't think we need a custom renderer or
> plugin. Apparently, we can get what we want by enclosing everything
> coming from bugzilla within: {noformat:nopanel=true}
>
> That way, we still have the option of using the normal rendering for
> new issues (or even editing old issues to move "nicer parts" out of
> the noformat block), and only put inside a noformat block the things
> which really need to be monospaced.
>
> See here for an example:
>
> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>
>
>
> --
> Johan
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
Tigris runs Issuezilla which was a fork of Bugzilla.
Scarab is another tracker CollabNet started and is or was a project on
tigris. It is also included in the product but not turned on for tigris
projects. It is called "Project Tracker" in the CEE product line.
Mark
On Wed, Sep 16, 2015 at 7:07 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Just noting: The issue tracker we used on tigris is based on Scarab, not
> on bugzilla.
>
> So we are not converting from bugzilla... Bugzilla is just another option
> that would need a different migration.
>
> Bert
> ------------------------------
> From: Johan Corveleyn <jc...@gmail.com>
> Sent: 16-9-2015 12:08
> To: Ivan Zhakov <iv...@visualsvn.com>
> Cc: Stefan Hett <st...@egosoft.com>; Stefan <lu...@posteo.de>; Daniel
> Shahaf <d....@daniel.shahaf.name>; Julian Foad <ju...@btopenworld.com>;
> Bert Huijben <be...@qqmail.nl>; dev <de...@subversion.apache.org>
> Subject: Re: Migrating Subversion issues to ...
>
> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> > On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
> >> Hi,
> >>>>
> >>>> Speaking about Ivan's suggested monospace-renderer-plugin and the
> concern
> >>>> that it might break with a future version of JIRA: My experience with
> >>>> JIRA
> >>>> (which dates back to around 2005 I guess) is that Atlassian is quite
> >>>> reluctant with introducing changes which break plugins. So it's quite
> >>>> rare
> >>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
> >>>> Things
> >>>> are slightly different when the major version numbers change, but then
> >>>> this
> >>>> only happens every 2 years or so. Hence the maintenance work for such
> a
> >>>> plugin should be considered quite low in the general case.
> >>>> On the other side Atlassian requires plugin developers to maintain and
> >>>> test
> >>>> their plugins on a regular basis (so they are still ensured to be
> >>>> compatible
> >>>> with later versions).
> >>>> If that's some concern and there is some help wanted/needed, I'd be
> >>>> willing
> >>>> to offer Ivan a hand with the maintenance work on his plugin (if that
> >>>> would
> >>>> help). As a test environment I'd provide my own JIRA instance, so that
> >>>> would
> >>>> not add much workload to me.
> >>>>
> >>> Thanks for offering help, but I already have test JIRA instance at my
> >>> office that I used for Serf project issues migration.
> >>>
> >>> Btw do you have any experience in writing JIRA plugins? Writing
> >>> monospaced (preformated) text render would be big help.
> >>
> >> Unfortunately not at all, otherwise I would have offered to do so.
> >> While I do have some decent knowledge of Java due to my studies, I
> haven't
> >> been coding in Java for several years now and don't even have a
> development
> >> environment set-up for that.
> >>
> > I also don't have Java environment, while I developed several plugins
> > more then 10 years ago.
> > Link to the Atlassian tutorial if ever want to learn it:
> >
> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
> >
>
> I think we're almost there: I don't think we need a custom renderer or
> plugin. Apparently, we can get what we want by enclosing everything
> coming from bugzilla within: {noformat:nopanel=true}
>
> That way, we still have the option of using the normal rendering for
> new issues (or even editing old issues to move "nicer parts" out of
> the noformat block), and only put inside a noformat block the things
> which really need to be monospaced.
>
> See here for an example:
>
> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>
>
>
> --
> Johan
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
That is just not true, Bert.
Subversion uses "IssueZilla" which is a CollabNet derivation of Bugzilla.
On Wed, Sep 16, 2015 at 6:07 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Just noting: The issue tracker we used on tigris is based on Scarab, not
> on bugzilla.
>
> So we are not converting from bugzilla... Bugzilla is just another option
> that would need a different migration.
>
> Bert
> ------------------------------
> From: Johan Corveleyn <jc...@gmail.com>
> Sent: 16-9-2015 12:08
> To: Ivan Zhakov <iv...@visualsvn.com>
> Cc: Stefan Hett <st...@egosoft.com>; Stefan <lu...@posteo.de>; Daniel
> Shahaf <d....@daniel.shahaf.name>; Julian Foad <ju...@btopenworld.com>;
> Bert Huijben <be...@qqmail.nl>; dev <de...@subversion.apache.org>
> Subject: Re: Migrating Subversion issues to ...
>
> On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> > On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
> >> Hi,
> >>>>
> >>>> Speaking about Ivan's suggested monospace-renderer-plugin and the
> concern
> >>>> that it might break with a future version of JIRA: My experience with
> >>>> JIRA
> >>>> (which dates back to around 2005 I guess) is that Atlassian is quite
> >>>> reluctant with introducing changes which break plugins. So it's quite
> >>>> rare
> >>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
> >>>> Things
> >>>> are slightly different when the major version numbers change, but then
> >>>> this
> >>>> only happens every 2 years or so. Hence the maintenance work for such
> a
> >>>> plugin should be considered quite low in the general case.
> >>>> On the other side Atlassian requires plugin developers to maintain and
> >>>> test
> >>>> their plugins on a regular basis (so they are still ensured to be
> >>>> compatible
> >>>> with later versions).
> >>>> If that's some concern and there is some help wanted/needed, I'd be
> >>>> willing
> >>>> to offer Ivan a hand with the maintenance work on his plugin (if that
> >>>> would
> >>>> help). As a test environment I'd provide my own JIRA instance, so that
> >>>> would
> >>>> not add much workload to me.
> >>>>
> >>> Thanks for offering help, but I already have test JIRA instance at my
> >>> office that I used for Serf project issues migration.
> >>>
> >>> Btw do you have any experience in writing JIRA plugins? Writing
> >>> monospaced (preformated) text render would be big help.
> >>
> >> Unfortunately not at all, otherwise I would have offered to do so.
> >> While I do have some decent knowledge of Java due to my studies, I
> haven't
> >> been coding in Java for several years now and don't even have a
> development
> >> environment set-up for that.
> >>
> > I also don't have Java environment, while I developed several plugins
> > more then 10 years ago.
> > Link to the Atlassian tutorial if ever want to learn it:
> >
> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
> >
>
> I think we're almost there: I don't think we need a custom renderer or
> plugin. Apparently, we can get what we want by enclosing everything
> coming from bugzilla within: {noformat:nopanel=true}
>
> That way, we still have the option of using the normal rendering for
> new issues (or even editing old issues to move "nicer parts" out of
> the noformat block), and only put inside a noformat block the things
> which really need to be monospaced.
>
> See here for an example:
>
> https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
>
>
>
> --
> Johan
>
RE: Migrating Subversion issues to ...
Posted by Bert Huijben <be...@qqmail.nl>.
Just noting: The issue tracker we used on tigris is based on Scarab, not on bugzilla.
So we are not converting from bugzilla... Bugzilla is just another option that would need a different migration.
Bert
-----Original Message-----
From: "Johan Corveleyn" <jc...@gmail.com>
Sent: 16-9-2015 12:08
To: "Ivan Zhakov" <iv...@visualsvn.com>
Cc: "Stefan Hett" <st...@egosoft.com>; "Stefan" <lu...@posteo.de>; "Daniel Shahaf" <d....@daniel.shahaf.name>; "Julian Foad" <ju...@btopenworld.com>; "Bert Huijben" <be...@qqmail.nl>; "dev" <de...@subversion.apache.org>
Subject: Re: Migrating Subversion issues to ...
On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
>> Hi,
>>>>
>>>> Speaking about Ivan's suggested monospace-renderer-plugin and the concern
>>>> that it might break with a future version of JIRA: My experience with
>>>> JIRA
>>>> (which dates back to around 2005 I guess) is that Atlassian is quite
>>>> reluctant with introducing changes which break plugins. So it's quite
>>>> rare
>>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
>>>> Things
>>>> are slightly different when the major version numbers change, but then
>>>> this
>>>> only happens every 2 years or so. Hence the maintenance work for such a
>>>> plugin should be considered quite low in the general case.
>>>> On the other side Atlassian requires plugin developers to maintain and
>>>> test
>>>> their plugins on a regular basis (so they are still ensured to be
>>>> compatible
>>>> with later versions).
>>>> If that's some concern and there is some help wanted/needed, I'd be
>>>> willing
>>>> to offer Ivan a hand with the maintenance work on his plugin (if that
>>>> would
>>>> help). As a test environment I'd provide my own JIRA instance, so that
>>>> would
>>>> not add much workload to me.
>>>>
>>> Thanks for offering help, but I already have test JIRA instance at my
>>> office that I used for Serf project issues migration.
>>>
>>> Btw do you have any experience in writing JIRA plugins? Writing
>>> monospaced (preformated) text render would be big help.
>>
>> Unfortunately not at all, otherwise I would have offered to do so.
>> While I do have some decent knowledge of Java due to my studies, I haven't
>> been coding in Java for several years now and don't even have a development
>> environment set-up for that.
>>
> I also don't have Java environment, while I developed several plugins
> more then 10 years ago.
> Link to the Atlassian tutorial if ever want to learn it:
> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
>
I think we're almost there: I don't think we need a custom renderer or
plugin. Apparently, we can get what we want by enclosing everything
coming from bugzilla within: {noformat:nopanel=true}
That way, we still have the option of using the normal rendering for
new issues (or even editing old issues to move "nicer parts" out of
the noformat block), and only put inside a noformat block the things
which really need to be monospaced.
See here for an example:
https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
--
Johan
Re: Migrating Subversion issues to ...
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Sep 16, 2015 at 11:59 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
>> Hi,
>>>>
>>>> Speaking about Ivan's suggested monospace-renderer-plugin and the concern
>>>> that it might break with a future version of JIRA: My experience with
>>>> JIRA
>>>> (which dates back to around 2005 I guess) is that Atlassian is quite
>>>> reluctant with introducing changes which break plugins. So it's quite
>>>> rare
>>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
>>>> Things
>>>> are slightly different when the major version numbers change, but then
>>>> this
>>>> only happens every 2 years or so. Hence the maintenance work for such a
>>>> plugin should be considered quite low in the general case.
>>>> On the other side Atlassian requires plugin developers to maintain and
>>>> test
>>>> their plugins on a regular basis (so they are still ensured to be
>>>> compatible
>>>> with later versions).
>>>> If that's some concern and there is some help wanted/needed, I'd be
>>>> willing
>>>> to offer Ivan a hand with the maintenance work on his plugin (if that
>>>> would
>>>> help). As a test environment I'd provide my own JIRA instance, so that
>>>> would
>>>> not add much workload to me.
>>>>
>>> Thanks for offering help, but I already have test JIRA instance at my
>>> office that I used for Serf project issues migration.
>>>
>>> Btw do you have any experience in writing JIRA plugins? Writing
>>> monospaced (preformated) text render would be big help.
>>
>> Unfortunately not at all, otherwise I would have offered to do so.
>> While I do have some decent knowledge of Java due to my studies, I haven't
>> been coding in Java for several years now and don't even have a development
>> environment set-up for that.
>>
> I also don't have Java environment, while I developed several plugins
> more then 10 years ago.
> Link to the Atlassian tutorial if ever want to learn it:
> https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
>
I think we're almost there: I don't think we need a custom renderer or
plugin. Apparently, we can get what we want by enclosing everything
coming from bugzilla within: {noformat:nopanel=true}
That way, we still have the option of using the normal rendering for
new issues (or even editing old issues to move "nicer parts" out of
the noformat block), and only put inside a noformat block the things
which really need to be monospaced.
See here for an example:
https://issues.apache.org/jira/browse/TST-210?focusedCommentId=14747248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14747248
--
Johan
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 September 2015 at 11:32, Stefan Hett <st...@egosoft.com> wrote:
> Hi,
>>>
>>> Speaking about Ivan's suggested monospace-renderer-plugin and the concern
>>> that it might break with a future version of JIRA: My experience with
>>> JIRA
>>> (which dates back to around 2005 I guess) is that Atlassian is quite
>>> reluctant with introducing changes which break plugins. So it's quite
>>> rare
>>> that that a plugin which works in 6.0 breaks during the 6.x releases.
>>> Things
>>> are slightly different when the major version numbers change, but then
>>> this
>>> only happens every 2 years or so. Hence the maintenance work for such a
>>> plugin should be considered quite low in the general case.
>>> On the other side Atlassian requires plugin developers to maintain and
>>> test
>>> their plugins on a regular basis (so they are still ensured to be
>>> compatible
>>> with later versions).
>>> If that's some concern and there is some help wanted/needed, I'd be
>>> willing
>>> to offer Ivan a hand with the maintenance work on his plugin (if that
>>> would
>>> help). As a test environment I'd provide my own JIRA instance, so that
>>> would
>>> not add much workload to me.
>>>
>> Thanks for offering help, but I already have test JIRA instance at my
>> office that I used for Serf project issues migration.
>>
>> Btw do you have any experience in writing JIRA plugins? Writing
>> monospaced (preformated) text render would be big help.
>
> Unfortunately not at all, otherwise I would have offered to do so.
> While I do have some decent knowledge of Java due to my studies, I haven't
> been coding in Java for several years now and don't even have a development
> environment set-up for that.
>
I also don't have Java environment, while I developed several plugins
more then 10 years ago.
Link to the Atlassian tutorial if ever want to learn it:
https://developer.atlassian.com/docs/getting-started/set-up-the-atlassian-plugin-sdk-and-build-a-project
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Stefan Hett <st...@egosoft.com>.
Hi,
>> Speaking about Ivan's suggested monospace-renderer-plugin and the concern
>> that it might break with a future version of JIRA: My experience with JIRA
>> (which dates back to around 2005 I guess) is that Atlassian is quite
>> reluctant with introducing changes which break plugins. So it's quite rare
>> that that a plugin which works in 6.0 breaks during the 6.x releases. Things
>> are slightly different when the major version numbers change, but then this
>> only happens every 2 years or so. Hence the maintenance work for such a
>> plugin should be considered quite low in the general case.
>> On the other side Atlassian requires plugin developers to maintain and test
>> their plugins on a regular basis (so they are still ensured to be compatible
>> with later versions).
>> If that's some concern and there is some help wanted/needed, I'd be willing
>> to offer Ivan a hand with the maintenance work on his plugin (if that would
>> help). As a test environment I'd provide my own JIRA instance, so that would
>> not add much workload to me.
>>
> Thanks for offering help, but I already have test JIRA instance at my
> office that I used for Serf project issues migration.
>
> Btw do you have any experience in writing JIRA plugins? Writing
> monospaced (preformated) text render would be big help.
Unfortunately not at all, otherwise I would have offered to do so.
While I do have some decent knowledge of Java due to my studies, I
haven't been coding in Java for several years now and don't even have a
development environment set-up for that.
--
Regards,
Stefan Hett
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 September 2015 at 02:43, Stefan <lu...@posteo.de> wrote:
> Hi,
>>
>> [...]
>>
>> 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.
>>
>> [...]
>
> I needed to be convinced by brane and jamessan on IRC that it's better to
> send this reply to the list directly rather than by IRC. ;-)
>
> Don't take this reply the wrong way please. I'm not trying to talk the one
> person who speaks up in favor for bugzilla into anything.
> Just wanted to point out that you (i.e. the subversion developers) are
> certainly not the first ones to bring-up the limitations of monospace
> support in JIRA. See: https://jira.atlassian.com/browse/JRA-37076 (issue
> regarding the added scrollbars when using monospace).
> Since the issue is on record for Atlassian, there's actually some chance
> that it gets resolved at some point (the more votes it gets, the more likely
> it will be taken care of at one point).
>
> On the other side I don't want to hide anything, so there are also the known
> issues with monospace in JIRA atm:
> https://jira.atlassian.com/browse/JRA-39011?jql=project%20%3D%20JRA%20AND%20status%20%3D%20Open%20AND%20text%20~%20%22monospace%22
>
We have to use {normat} tag instead of {monospaced} since we need to
preserve spaces to keep ascii graphics, etc.
> Speaking about Ivan's suggested monospace-renderer-plugin and the concern
> that it might break with a future version of JIRA: My experience with JIRA
> (which dates back to around 2005 I guess) is that Atlassian is quite
> reluctant with introducing changes which break plugins. So it's quite rare
> that that a plugin which works in 6.0 breaks during the 6.x releases. Things
> are slightly different when the major version numbers change, but then this
> only happens every 2 years or so. Hence the maintenance work for such a
> plugin should be considered quite low in the general case.
> On the other side Atlassian requires plugin developers to maintain and test
> their plugins on a regular basis (so they are still ensured to be compatible
> with later versions).
> If that's some concern and there is some help wanted/needed, I'd be willing
> to offer Ivan a hand with the maintenance work on his plugin (if that would
> help). As a test environment I'd provide my own JIRA instance, so that would
> not add much workload to me.
>
Thanks for offering help, but I already have test JIRA instance at my
office that I used for Serf project issues migration.
Btw do you have any experience in writing JIRA plugins? Writing
monospaced (preformated) text render would be big help.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Stefan <lu...@posteo.de>.
Hi,
> [...]
>
> 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.
>
> [...]
I needed to be convinced by brane and jamessan on IRC that it's better
to send this reply to the list directly rather than by IRC. ;-)
Don't take this reply the wrong way please. I'm not trying to talk the
one person who speaks up in favor for bugzilla into anything.
Just wanted to point out that you (i.e. the subversion developers) are
certainly not the first ones to bring-up the limitations of monospace
support in JIRA. See: https://jira.atlassian.com/browse/JRA-37076 (issue
regarding the added scrollbars when using monospace).
Since the issue is on record for Atlassian, there's actually some chance
that it gets resolved at some point (the more votes it gets, the more
likely it will be taken care of at one point).
On the other side I don't want to hide anything, so there are also the
known issues with monospace in JIRA atm:
https://jira.atlassian.com/browse/JRA-39011?jql=project%20%3D%20JRA%20AND%20status%20%3D%20Open%20AND%20text%20~%20%22monospace%22
I couldn't spot anything which IMO would speak against using JIRA here
on that list, but since this is quite a subjective matter, I guess
everybody has to determine himself whether any of the listed issues is a
concern to himself.
Speaking about Ivan's suggested monospace-renderer-plugin and the
concern that it might break with a future version of JIRA: My experience
with JIRA (which dates back to around 2005 I guess) is that Atlassian is
quite reluctant with introducing changes which break plugins. So it's
quite rare that that a plugin which works in 6.0 breaks during the 6.x
releases. Things are slightly different when the major version numbers
change, but then this only happens every 2 years or so. Hence the
maintenance work for such a plugin should be considered quite low in the
general case.
On the other side Atlassian requires plugin developers to maintain and
test their plugins on a regular basis (so they are still ensured to be
compatible with later versions).
If that's some concern and there is some help wanted/needed, I'd be
willing to offer Ivan a hand with the maintenance work on his plugin (if
that would help). As a test environment I'd provide my own JIRA
instance, so that would not add much workload to me.
Regards,
Stefan
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 September 2015 at 02:19, Branko Čibej <br...@apache.org> wrote:
> 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
> simple.
>
>> 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 think that formatting of issue description and comments is kind of
blocker for JIRA migration and should be solved somehow: using
{noformat} tag and fixing scrollbars issue or using custom plugin
> 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.
>
+1.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
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
simple.
> 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
Re: Migrating Subversion issues to ...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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.
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.
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).
Cheers,
Daniel
> * 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
Re: Migrating Subversion issues to ...
Posted by Julian Foad <ju...@btopenworld.com>.
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.
Ivan mentioned that doing it now, while he's willing and able to do
so, may be a good idea because at some point Tigris may just go away
with not enough notice for anybody to step up and do the migration at
that time.
>> [ ] 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):
* 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
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 15 September 2015 at 11:59, Bert Huijben <be...@qqmail.nl> wrote:
> Hi All,
>
Thanks for moving this discussion to the list!
> Here at the hackathon in Berlin we are discussing issue trackers, and more
> particular how we should eventually move our issues to ASF infrastructure.
> An old TODO.
>
> Ivan just converted the data of the much smaller Serf issuetracker to Jira
> for the Apache Serf project, and he offers to perform the migration for
> Subversion too.
>
> I think we really have 3 options:
>
> [ ] Keep our issues on Tigris
> [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
> [ ] Migrate to the standard ASF Jira installation
>
Migration to ASF Jira instalation seems to be best option for me: JIRA
is very flexible and have nicer interface.
I've performed test migrations of Subversion issues to JIRA in the
past and the only problem is that currently issues on tigris.org uses
monospaced formatting for description and comments. JIRA by default
uses proportional fonts and ascii graphics looks bad with such fonts.
One option to resolve this would be create JIRA plugin with very
simple "field renderer" that uses monospaced font. Field renderer is
configured per project, so it's technically possible to use it on
shared ASF JIRA installation. The only question is whether ASF infra
allow us to install such simple plugin (or develop it for us?).
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 September 2015 at 23:12, Greg Stein <gs...@gmail.com> wrote:
> Could I offer an opinion: the time stamps DO NOT MATTER.
>
> If a comment was posted at 15:00 or at 21:00 ... I don't care. If it was a
> Monday or a Tuesday ... I don't care. I believe I'd rather stick a fork in
> my eye, than ask somebody to spend even 5 minutes on timestamps.
>
Seriously? I think that timestamps is very important part of
information in issue tracker and we should preserve them exact,
regardless how them were exported or stored on tigris.org. I could
imagine that someday we introduce the policy to only fix issues filed
in the afternoon, but close as Invalid issues that are filed at night.
PS: I'm kidding of course :)
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Sep 16, 2015 at 11:12 PM, Greg Stein <gs...@gmail.com> wrote:
> Could I offer an opinion: the time stamps DO NOT MATTER.
>
> If a comment was posted at 15:00 or at 21:00 ... I don't care. If it was a
> Monday or a Tuesday ... I don't care. I believe I'd rather stick a fork in
> my eye, than ask somebody to spend even 5 minutes on timestamps.
LOL. "Fork in my eye", that gave me a nice Pirates of the Caribbean image :-).
--
Johan
Re: Migrating Subversion issues to ...
Posted by Julian Foad <ju...@btopenworld.com>.
>>> Julian Foad wrote:
>>>> That's closer, but not correct. I checked some issue notification
>>>> emails to be sure.
>>>>
>>>> The time stamps in the PDT portion of any year are now converted
>>>> correctly, but the time stamps in the PST (UTC-0800) portion of any
>>>> year are now converted to one hour less than the correct value.
Ivan has fixed it now. He just showed me his latest conversion, of issue #3529.
Tigris display (HTML):
Additional comments from Hyrum K. Wright Tue Aug 17 16:38:22 -0700 2010
Additional comments from Hyrum K. Wright Wed Feb 2 14:23:36 -0700 2011
Tigris XML:
<who>hwright</who><issue_when>2010-08-17 16:38:22</issue_when>
<who>hwright</who><issue_when>2011-02-02 13:23:36</issue_when>
Note that these times are given in XML with different hour offsets,
but the offsets are not explicitly stated -- more details are in my
previous email.
JIRA display (HTML):
Hyrum Wright added a comment - 18/Aug/10 00:38
Hyrum Wright added a comment - 02/Feb/11 21:23
JIRA XML:
<comment id="14800990" author="hwright" created="Wed, 18 Aug 2010
00:38:22 +0100" >
<comment id="14800991" author="hwright" created="Wed, 2 Feb 2011
21:23:36 +0000" >
Note the different, explicit offsets: thus, these times differ by 2
hours (plus an integer number of days).
- Julian
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 18.09.2015 05:25, Greg Stein wrote:
> On Thu, Sep 17, 2015 at 9:20 PM, Branko Čibej <br...@apache.org> wrote:
>> ...
>> mantra and this sudden urgency to migrate the issue tracker yesterday. If
>> we waited for 5 years we may as well wait the couple extra days to get the
>> details right.
>>
> Or, in a couple days, Ivan departs the hackathon, gets caught up in a day
> of travel, hits the weekend, returns to work on Monday, gets involved in
> $dayjob, and ...
>
> 5 years later, we have never migrated our issues.
Yes, that could happen.
-- Brane
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Sep 17, 2015 at 9:20 PM, Branko Čibej <br...@apache.org> wrote:
>...
> mantra and this sudden urgency to migrate the issue tracker yesterday. If
> we waited for 5 years we may as well wait the couple extra days to get the
> details right.
>
Or, in a couple days, Ivan departs the hackathon, gets caught up in a day
of travel, hits the weekend, returns to work on Monday, gets involved in
$dayjob, and ...
5 years later, we have never migrated our issues.
-g
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 17 Sep 2015 8:56 pm, "Greg Stein" <gs...@gmail.com> wrote:
>
>
>
> On Thu, Sep 17, 2015 at 7:18 AM, Mark Phippard <ma...@gmail.com> wrote:
>>
>> On Thu, Sep 17, 2015 at 3:31 AM, Branko Čibej <br...@apache.org> wrote:
>
> >...
>>>
>>> And I wonder why the people who're doing the least work on this
>>> migration have the most to say about not wasting time with
"trivialities".
>>
>>
>> Speaking for myself only, it is because I am not "in the room" with the
rest of you so cannot tell if the migration is going to happen no matter
what, or if it is going to get delayed again due to these trivialities. As
long as you all have the energy to see this through, I certainly do not
want to suggest you should not fix all of the trivialities that you
desire. I just do not want the moment to pass again and have people go
back home and move on to other things.
>>
>> So my goal is just to say an imperfect migration is better than the
status quo.
>
>
> Exactly.
>
> And Branko: what does it matter what we say? People can still put their
time into anything they want.
Of course it matters. I'm just trying to gently hint at the discrepancy
between our "release when it's ready" mantra and this sudden urgency to
migrate the issue tracker yesterday. If we waited for 5 years we may as
well wait the couple extra days to get the details right.
-- Brane
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Sep 17, 2015 at 7:18 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Thu, Sep 17, 2015 at 3:31 AM, Branko Čibej <br...@apache.org> wrote:
>
>...
> And I wonder why the people who're doing the least work on this
>> migration have the most to say about not wasting time with "trivialities".
>>
>
> Speaking for myself only, it is because I am not "in the room" with the
> rest of you so cannot tell if the migration is going to happen no matter
> what, or if it is going to get delayed again due to these trivialities. As
> long as you all have the energy to see this through, I certainly do not
> want to suggest you should not fix all of the trivialities that you
> desire. I just do not want the moment to pass again and have people go
> back home and move on to other things.
>
> So my goal is just to say an imperfect migration is better than the status
> quo.
>
Exactly.
And Branko: what does it matter what we say? People can still put their
time into anything they want.
-g
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Sep 17, 2015 at 3:31 AM, Branko Čibej <br...@apache.org> wrote:
> On 17.09.2015 09:06, Julian Foad wrote:
> > Greg Stein wrote:
> >> Could I offer an opinion: the time stamps DO NOT MATTER.
> >>
> >> If a comment was posted at 15:00 or at 21:00 ... I don't care. If it
> was a
> >> Monday or a Tuesday ... I don't care. I believe I'd rather stick a fork
> in
> >> my eye, than ask somebody to spend even 5 minutes on timestamps.
> > Yes, I *know* they don't matter! Oops -- I should have added some
> > light-heartedness, a smiley, or whatever, instead of just writing in
> > plain serious tone.
> >
> > Ivan was sitting two metres from me and I told him in person, and I
> > made fun of my own pedantry.
> >
> > But I do have a serious point, and that is I feel sad when we, the
> > whole profession and community of dedicated and experienced
> > programmers, can't get such a simple thing right. (I don't mean just
> > on our side -- there are long-standing bugs filed against Bugzilla
> > about their end of this difficulty.) It's a little bit embarrassing to
> > me when we put up a public resource that will live for years with such
> > a simple mistake in it. I have sympathy for the "so what, who cares,
> > just spit something out and move on" prioritization here. That makes
> > sense in terms of value for "money". But for the above kinds of
> > reason, I do think it's right for us to spend a few minutes, even a
> > couple of hours, checking and correcting this sort of issue, *if*
> > somebody such as Ivan wants to donate that effort.
>
> +1
>
> > (It was already established that we'll be waiting at least a few days
> > for polling people about their user names, and other reasons, so we're
> > not talking about a critical-path delay.)
>
> 5+ years since becoming an ASF TLP is hardly on any kind of critical
> path. :)
>
> And I wonder why the people who're doing the least work on this
> migration have the most to say about not wasting time with "trivialities".
>
>
Speaking for myself only, it is because I am not "in the room" with the
rest of you so cannot tell if the migration is going to happen no matter
what, or if it is going to get delayed again due to these trivialities. As
long as you all have the energy to see this through, I certainly do not
want to suggest you should not fix all of the trivialities that you
desire. I just do not want the moment to pass again and have people go
back home and move on to other things.
So my goal is just to say an imperfect migration is better than the status
quo.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 17.09.2015 09:06, Julian Foad wrote:
> Greg Stein wrote:
>> Could I offer an opinion: the time stamps DO NOT MATTER.
>>
>> If a comment was posted at 15:00 or at 21:00 ... I don't care. If it was a
>> Monday or a Tuesday ... I don't care. I believe I'd rather stick a fork in
>> my eye, than ask somebody to spend even 5 minutes on timestamps.
> Yes, I *know* they don't matter! Oops -- I should have added some
> light-heartedness, a smiley, or whatever, instead of just writing in
> plain serious tone.
>
> Ivan was sitting two metres from me and I told him in person, and I
> made fun of my own pedantry.
>
> But I do have a serious point, and that is I feel sad when we, the
> whole profession and community of dedicated and experienced
> programmers, can't get such a simple thing right. (I don't mean just
> on our side -- there are long-standing bugs filed against Bugzilla
> about their end of this difficulty.) It's a little bit embarrassing to
> me when we put up a public resource that will live for years with such
> a simple mistake in it. I have sympathy for the "so what, who cares,
> just spit something out and move on" prioritization here. That makes
> sense in terms of value for "money". But for the above kinds of
> reason, I do think it's right for us to spend a few minutes, even a
> couple of hours, checking and correcting this sort of issue, *if*
> somebody such as Ivan wants to donate that effort.
+1
> (It was already established that we'll be waiting at least a few days
> for polling people about their user names, and other reasons, so we're
> not talking about a critical-path delay.)
5+ years since becoming an ASF TLP is hardly on any kind of critical
path. :)
And I wonder why the people who're doing the least work on this
migration have the most to say about not wasting time with "trivialities".
-- Brane
>> Julian Foad wrote:
>>> That's closer, but not correct. I checked some issue notification
>>> emails to be sure.
>>>
>>> The time stamps in the PDT portion of any year are now converted
>>> correctly, but the time stamps in the PST (UTC-0800) portion of any
>>> year are now converted to one hour less than the correct value.
> [...]
>
> - Julian
Re: Migrating Subversion issues to ...
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Stein wrote:
> Could I offer an opinion: the time stamps DO NOT MATTER.
>
> If a comment was posted at 15:00 or at 21:00 ... I don't care. If it was a
> Monday or a Tuesday ... I don't care. I believe I'd rather stick a fork in
> my eye, than ask somebody to spend even 5 minutes on timestamps.
Yes, I *know* they don't matter! Oops -- I should have added some
light-heartedness, a smiley, or whatever, instead of just writing in
plain serious tone.
Ivan was sitting two metres from me and I told him in person, and I
made fun of my own pedantry.
But I do have a serious point, and that is I feel sad when we, the
whole profession and community of dedicated and experienced
programmers, can't get such a simple thing right. (I don't mean just
on our side -- there are long-standing bugs filed against Bugzilla
about their end of this difficulty.) It's a little bit embarrassing to
me when we put up a public resource that will live for years with such
a simple mistake in it. I have sympathy for the "so what, who cares,
just spit something out and move on" prioritization here. That makes
sense in terms of value for "money". But for the above kinds of
reason, I do think it's right for us to spend a few minutes, even a
couple of hours, checking and correcting this sort of issue, *if*
somebody such as Ivan wants to donate that effort.
(It was already established that we'll be waiting at least a few days
for polling people about their user names, and other reasons, so we're
not talking about a critical-path delay.)
- Julian
> Julian Foad wrote:
>> That's closer, but not correct. I checked some issue notification
>> emails to be sure.
>>
>> The time stamps in the PDT portion of any year are now converted
>> correctly, but the time stamps in the PST (UTC-0800) portion of any
>> year are now converted to one hour less than the correct value.
[...]
- Julian
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
Could I offer an opinion: the time stamps DO NOT MATTER.
If a comment was posted at 15:00 or at 21:00 ... I don't care. If it was a
Monday or a Tuesday ... I don't care. I believe I'd rather stick a fork in
my eye, than ask somebody to spend even 5 minutes on timestamps.
Cheers,
-g
On Wed, Sep 16, 2015 at 11:14 AM, Julian Foad <ju...@btopenworld.com>
wrote:
> Ivan Zhakov wrote:
> > Julian Foad wrote:
> >> The time zone offset appears not to be handled correctly in converting
> >> time stamps (on Dates: Created, Updated; and on Comments).
> >>
> >> # http://subversion.tigris.org/issues/show_bug.cgi?id=1532
> >> Opened: Tue Sep 23 10:02:00 -0700 2003
> >> ------- Additional comments from Peter N. Lundblad Thu Jan 12 05:42:25
> >> -0700 2006 -------
> >> ------- Additional comments from Peter N. Lundblad Tue May 2 02:21:02
> >> -0700 2006 -------
> >> ------- Additional comments from Julian Foad Tue Feb 17 09:41:24 -0700
> >> 2015 -------
> >>
> >> # http://subversion.tigris.org/issues/xml.cgi?id=1532
> >> <creation_ts>2003-09-23 10:02:50</creation_ts>
> >> <who>lundblad</who><issue_when>2006-01-12 04:42:25</issue_when>
> >> <who>lundblad</who><issue_when>2006-05-02 02:21:02</issue_when>
> >> <user>julianfoad</user><when>2015-02-17 08:41:24</when>
> >>
> >> # https://issues.apache.org/jira/browse/SVN-1532
> >> Created: 23/Sep/03 11:02
> >> Updated: 17/Feb/15 08:41
> >> Subversion Importer added a comment - 12/Jan/06 04:42
> >> Subversion Importer added a comment - 02/May/06 03:21
> >>
> >> The time zone in my Jira profile is set to London (GMT+00), and
> >> probably assumes something about how to display local times in BST
> >> (GMT+01).
> >
> > It should be fixed now. Please note that issue tracker on tigris.org
> > displays time always in (-0700) timezone, while JIRA display in
> > user-configured timezone.
>
> That's closer, but not correct. I checked some issue notification
> emails to be sure.
>
> The time stamps in the PDT portion of any year are now converted
> correctly, but the time stamps in the PST (UTC-0800) portion of any
> year are now converted to one hour less than the correct value.
>
> I think the XML export from Tigris expresses a timestamp using PDT
> (UTC-0700) if the timestamp date is in the PDT portion of the year,
> and using PST (UTC-0800) if the timestamp date is in the PST portion
> of the year. I guess you assumed they are all in PDT?
>
> I do not know exactly what algorithm the Tigris export uses for "PDT
> portion of the year". However, the normal HTML view on Tigris is
> (currently) displaying all timestamps as PDT (UTC-0700).
>
> In issue #4594, Bert commented at:
> = 15:58 CEST (UTC+0200) (personally confirmed)
> = 14:58 BST (UTC+0100)
> = 13:58 UTC
> = 06:58 PDT (UTC-0700)
>
> => For a time stamp made today (in the DST portion of the year),
> IssueZilla now reports it in PDT in both HTML (labeled as "(+0700)")
> and XML views (unlabeled).
>
> => For a time stamp made in the DST portion of any year, I assume the same.
>
> Julian's comment on issue #1532
> <
> http://permalink.gmane.org/gmane.comp.version-control.subversion.issues/27552
> >
> = 2015-02-17 16:41:24 GMT (header of notification email from Tigris)
> = Tue Feb 17 08:41:24 -0800 2015 (in notification email from Tigris)
>
> => For a time stamp made in the winter portion of any year, Tigris
> currently (in DST) reports one hour greater in HTML (still labeled as
> "(+0700)") than in XML (unlabeled).
> => The XML is therefore reporting the time as PST (UTC-0800) and I
> would guess the HTML is reporting it as Tigris local time (currently
> UTC-0700).
>
> - Julian
>
Re: Migrating Subversion issues to ...
Posted by Julian Foad <ju...@btopenworld.com>.
Ivan Zhakov wrote:
> Julian Foad wrote:
>> The time zone offset appears not to be handled correctly in converting
>> time stamps (on Dates: Created, Updated; and on Comments).
>>
>> # http://subversion.tigris.org/issues/show_bug.cgi?id=1532
>> Opened: Tue Sep 23 10:02:00 -0700 2003
>> ------- Additional comments from Peter N. Lundblad Thu Jan 12 05:42:25
>> -0700 2006 -------
>> ------- Additional comments from Peter N. Lundblad Tue May 2 02:21:02
>> -0700 2006 -------
>> ------- Additional comments from Julian Foad Tue Feb 17 09:41:24 -0700
>> 2015 -------
>>
>> # http://subversion.tigris.org/issues/xml.cgi?id=1532
>> <creation_ts>2003-09-23 10:02:50</creation_ts>
>> <who>lundblad</who><issue_when>2006-01-12 04:42:25</issue_when>
>> <who>lundblad</who><issue_when>2006-05-02 02:21:02</issue_when>
>> <user>julianfoad</user><when>2015-02-17 08:41:24</when>
>>
>> # https://issues.apache.org/jira/browse/SVN-1532
>> Created: 23/Sep/03 11:02
>> Updated: 17/Feb/15 08:41
>> Subversion Importer added a comment - 12/Jan/06 04:42
>> Subversion Importer added a comment - 02/May/06 03:21
>>
>> The time zone in my Jira profile is set to London (GMT+00), and
>> probably assumes something about how to display local times in BST
>> (GMT+01).
>
> It should be fixed now. Please note that issue tracker on tigris.org
> displays time always in (-0700) timezone, while JIRA display in
> user-configured timezone.
That's closer, but not correct. I checked some issue notification
emails to be sure.
The time stamps in the PDT portion of any year are now converted
correctly, but the time stamps in the PST (UTC-0800) portion of any
year are now converted to one hour less than the correct value.
I think the XML export from Tigris expresses a timestamp using PDT
(UTC-0700) if the timestamp date is in the PDT portion of the year,
and using PST (UTC-0800) if the timestamp date is in the PST portion
of the year. I guess you assumed they are all in PDT?
I do not know exactly what algorithm the Tigris export uses for "PDT
portion of the year". However, the normal HTML view on Tigris is
(currently) displaying all timestamps as PDT (UTC-0700).
In issue #4594, Bert commented at:
= 15:58 CEST (UTC+0200) (personally confirmed)
= 14:58 BST (UTC+0100)
= 13:58 UTC
= 06:58 PDT (UTC-0700)
=> For a time stamp made today (in the DST portion of the year),
IssueZilla now reports it in PDT in both HTML (labeled as "(+0700)")
and XML views (unlabeled).
=> For a time stamp made in the DST portion of any year, I assume the same.
Julian's comment on issue #1532
<http://permalink.gmane.org/gmane.comp.version-control.subversion.issues/27552>
= 2015-02-17 16:41:24 GMT (header of notification email from Tigris)
= Tue Feb 17 08:41:24 -0800 2015 (in notification email from Tigris)
=> For a time stamp made in the winter portion of any year, Tigris
currently (in DST) reports one hour greater in HTML (still labeled as
"(+0700)") than in XML (unlabeled).
=> The XML is therefore reporting the time as PST (UTC-0800) and I
would guess the HTML is reporting it as Tigris local time (currently
UTC-0700).
- Julian
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 September 2015 at 16:17, Julian Foad <ju...@btopenworld.com> wrote:
> Stefan Hett wrote:
>> Ivan Zhakov:
>>> Please report me any problems or suggestions. Current TODO list:
>>> - Migrate attachments
>>> - Preserve history of changes
>>
>> - released versions should be marked as such (preferably with their release
>> date) (as stated on IRC I can lend a hand if that needs to be done manually)
>
> The time zone offset appears not to be handled correctly in converting
> time stamps (on Dates: Created, Updated; and on Comments).
>
> # http://subversion.tigris.org/issues/show_bug.cgi?id=1532
> Opened: Tue Sep 23 10:02:00 -0700 2003
> ------- Additional comments from Peter N. Lundblad Thu Jan 12 05:42:25
> -0700 2006 -------
> ------- Additional comments from Peter N. Lundblad Tue May 2 02:21:02
> -0700 2006 -------
> ------- Additional comments from Julian Foad Tue Feb 17 09:41:24 -0700
> 2015 -------
>
> # http://subversion.tigris.org/issues/xml.cgi?id=1532
> <creation_ts>2003-09-23 10:02:50</creation_ts>
> <who>lundblad</who><issue_when>2006-01-12 04:42:25</issue_when>
> <who>lundblad</who><issue_when>2006-05-02 02:21:02</issue_when>
> <user>julianfoad</user><when>2015-02-17 08:41:24</when>
>
> # https://issues.apache.org/jira/browse/SVN-1532
> Created: 23/Sep/03 11:02
> Updated: 17/Feb/15 08:41
> Subversion Importer added a comment - 12/Jan/06 04:42
> Subversion Importer added a comment - 02/May/06 03:21
>
> The time zone in my Jira profile is set to London (GMT+00), and
> probably assumes something about how to display local times in BST
> (GMT+01).
>
It should be fixed now. Please note that issue tracker on tigris.org
displays time always in (-0700) timezone, while JIRA display in
user-configured timezone.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Hett wrote:
> Ivan Zhakov:
>> Please report me any problems or suggestions. Current TODO list:
>> - Migrate attachments
>> - Preserve history of changes
>
> - released versions should be marked as such (preferably with their release
> date) (as stated on IRC I can lend a hand if that needs to be done manually)
The time zone offset appears not to be handled correctly in converting
time stamps (on Dates: Created, Updated; and on Comments).
# http://subversion.tigris.org/issues/show_bug.cgi?id=1532
Opened: Tue Sep 23 10:02:00 -0700 2003
------- Additional comments from Peter N. Lundblad Thu Jan 12 05:42:25
-0700 2006 -------
------- Additional comments from Peter N. Lundblad Tue May 2 02:21:02
-0700 2006 -------
------- Additional comments from Julian Foad Tue Feb 17 09:41:24 -0700
2015 -------
# http://subversion.tigris.org/issues/xml.cgi?id=1532
<creation_ts>2003-09-23 10:02:50</creation_ts>
<who>lundblad</who><issue_when>2006-01-12 04:42:25</issue_when>
<who>lundblad</who><issue_when>2006-05-02 02:21:02</issue_when>
<user>julianfoad</user><when>2015-02-17 08:41:24</when>
# https://issues.apache.org/jira/browse/SVN-1532
Created: 23/Sep/03 11:02
Updated: 17/Feb/15 08:41
Subversion Importer added a comment - 12/Jan/06 04:42
Subversion Importer added a comment - 02/May/06 03:21
The time zone in my Jira profile is set to London (GMT+00), and
probably assumes something about how to display local times in BST
(GMT+01).
- Julian
Re: Migrating Subversion issues to ...
Posted by Stefan Hett <st...@egosoft.com>.
On 9/16/2015 2:44 PM, Ivan Zhakov wrote:
> On 15 September 2015 at 22:20, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 15 September 2015 at 20:02, Greg Stein <gs...@gmail.com> wrote:
>>> You can do it. File an INFRA ticket for porting our issues into JIRA, and
>>> note that you have some content for a test load. They do test loads often
>>> for incoming, so they have a runbook for that.
>>>
>>> (and post the INFRA ticket here, so others can Watch the ticket if they
>>> like)
>>>
>> Done:
>> https://issues.apache.org/jira/browse/INFRA-10439
>>
> Just to keep everyone updated: ASF Infra team performed first test
> migration for us:
> https://issues.apache.org/jira/browse/SVN
>
> Please report me any problems or suggestions. Current TODO list:
> - Migrate attachments
> - Preserve history of changes
- released versions should be marked as such (preferably with their
release date) (as stated on IRC I can lend a hand if that needs to be
done manually)
--
Regards,
Stefan Hett
Re: Migrating Subversion issues to ...
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Sep 16, 2015 at 8:44 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> Just to keep everyone updated: ASF Infra team performed first test
> migration for us:
> https://issues.apache.org/jira/browse/SVN
>
> Please report me any problems or suggestions. Current TODO list:
> - Migrate attachments
> - Preserve history of changes
Very cool - +1 for JIRA. Thanks for the efforts here!
Cheers. -- justin
Re: Migrating Subversion issues to ...
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 18, 2015 at 04:25:45PM +0200, Branko Čibej wrote:
> I've begun sending the mails, from my ASF account. I decided to send
> separate mails to each address, to avoid triggering spam filters as much as
> possible. I'm allowing lots of time between the mails so that I don't get
> accidentally blacklisted by the mail relay.
>
> I think we should wait for responses until the middle of next week.
What's wrong with just letting people sign up again as needed?
I doubt most people with an account in our trigris tracker still care.
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Sep 18, 2015 at 11:02 AM, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Sep 18, 2015 at 10:53:07AM -0400, Mark Phippard wrote:
> > I have unlocked the tigris project. Someone can ping me when it should
> be
> > locked again.
>
> BTW, every time the project is locked / unlocked I get multiple emails
> from tigris. We should not be doing this very often, I would suggest,
> to avoid spamming all the people who signed up over the years.
>
You are getting them from discussion lists you are subscribed to. I just
get 1, for the security list, but I would guess you could be subscribed to
issues@ as well. Are there any others? I doubt our users are subscribed
to these.
Anyway, I am not planning to do it multiple times. It sounded like we are
not doing the migration for a while so I assumed we wanted people to update
our issue tracker in the interim. I will leave it unlocked until someone
sends a definitive statement on when the migration is happening. At this
point, I will back out of that part of the discussion.
As long as Ivan feels he can do it in a week or so, I do not have a problem
waiting. I just want it to get done so we can be off tigris.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Migrating Subversion issues to ...
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 18, 2015 at 10:53:07AM -0400, Mark Phippard wrote:
> I have unlocked the tigris project. Someone can ping me when it should be
> locked again.
BTW, every time the project is locked / unlocked I get multiple emails
from tigris. We should not be doing this very often, I would suggest,
to avoid spamming all the people who signed up over the years.
RE: Migrating Subversion issues to ...
Posted by be...@qqmail.nl.
How many final migrations are we going to have until Ivan gives up and we’ll have to wait another 5 years for somebody to step up and do a migration?
If users have ten comments it’s easier for them to just create an account and start watching the same issue again, than for us to wait another week and do more handwork.
The users with > 100 comments should already be handled now.
Bert
From: Johan Corveleyn
Sent: vrijdag 18 september 2015 16:32
To: Branko Čibej
Cc: Ivan Zhakov;Subversion Development
Subject: Re: Migrating Subversion issues to ...
On Fri, Sep 18, 2015 at 4:25 PM, Branko Čibej <br...@apache.org> wrote:
> On 18 Sep 2015 4:16 pm, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>>
>> On 18 September 2015 at 16:10, Stefan Sperling <st...@elego.de> wrote:
>> > On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
>> >> Attachments was successfully migrated after multiple attempts and help
>> >> from ASF Infra team. This how Subversion issue tracker will look like:
>> >> https://issues.apache.org/jira/browse/SVN
>> >>
>> >> I'm ready to perform final migration, but I think we should make issue
>> >> tracker on tigris.org read only. It also would nice finalize tigris ->
>> >> asf user name mappings, at least for most referenced users.
>> >
>> > +1
>> >
>> > Please migrate ASAP.
>> Currently I'm waiting for tigris -> asf user mapping mails to @tigris
>> addresses.
>
> I've begun sending the mails, from my ASF account. I decided to send
> separate mails to each address, to avoid triggering spam filters as much as
> possible. I'm allowing lots of time between the mails so that I don't get
> accidentally blacklisted by the mail relay.
>
> I think we should wait for responses until the middle of next week.
>
+1. Some people will definitely appreciate this, and it's not like we
can't wait a couple more days ... (that is, if Ivan can find some
amount of time for the final run at the end of next week or so).
--
Johan
Re: Migrating Subversion issues to ...
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Sep 18, 2015 at 4:25 PM, Branko Čibej <br...@apache.org> wrote:
> On 18 Sep 2015 4:16 pm, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>>
>> On 18 September 2015 at 16:10, Stefan Sperling <st...@elego.de> wrote:
>> > On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
>> >> Attachments was successfully migrated after multiple attempts and help
>> >> from ASF Infra team. This how Subversion issue tracker will look like:
>> >> https://issues.apache.org/jira/browse/SVN
>> >>
>> >> I'm ready to perform final migration, but I think we should make issue
>> >> tracker on tigris.org read only. It also would nice finalize tigris ->
>> >> asf user name mappings, at least for most referenced users.
>> >
>> > +1
>> >
>> > Please migrate ASAP.
>> Currently I'm waiting for tigris -> asf user mapping mails to @tigris
>> addresses.
>
> I've begun sending the mails, from my ASF account. I decided to send
> separate mails to each address, to avoid triggering spam filters as much as
> possible. I'm allowing lots of time between the mails so that I don't get
> accidentally blacklisted by the mail relay.
>
> I think we should wait for responses until the middle of next week.
>
+1. Some people will definitely appreciate this, and it's not like we
can't wait a couple more days ... (that is, if Ivan can find some
amount of time for the final run at the end of next week or so).
--
Johan
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 18 September 2015 at 17:00, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Sep 18, 2015 at 04:56:04PM +0200, Ivan Zhakov wrote:
>> May be we can put issue tracker on tigris read-only: in this case I
>> could prepare everything today to avoid potential surprises and the
>> time of final migration. Any opinions?
>
> I would prefer we migrate today and don't wait for replies from people
> who may not even be interested.
>
> Any user who's not mapped right now can sign up on jira, and
> their old comments won't be linked to their account... *shrug*
>
> We can still see who made a comment, and that's all that really matters.
Personally I prefer to finish migration on Hackathon just to get thing
done and forget about this task. I think it doesn't matter. Waiting for
one week is not a problem -- we've been waiting for 5 years and one
week doesn't matter.
Branko has already sent emails to all tigris users and I started receiving
replies from users. The deadline is 28 Sep. I'm going to perform final
migration on 28 Sep.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 18, 2015 at 04:56:04PM +0200, Ivan Zhakov wrote:
> May be we can put issue tracker on tigris read-only: in this case I
> could prepare everything today to avoid potential surprises and the
> time of final migration. Any opinions?
I would prefer we migrate today and don't wait for replies from people
who may not even be interested.
Any user who's not mapped right now can sign up on jira, and
their old comments won't be linked to their account... *shrug*
We can still see who made a comment, and that's all that really matters.
Re: Migrating Subversion issues to ...
Posted by Stefan <lu...@posteo.de>.
On 05/10/2015 21:47, Julian Foad wrote:
> On 2 October 2015, Stefan wrote:
>> On 28/09/2015 16:48, Ivan Zhakov wrote:
>>> On 28 September 2015 at 13:59, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>> Anyone volunteering to update 'Reporting Issues' page [1]? The
>>> 'issue-tracker.html' page [2] on tigris.org could be used as template.
>>>
>>> [1] http://subversion.apache.org/reporting-issues.html
>>> [2] http://subversion.tigris.org/issue-tracker.html
>> Attached is a half-finished patch for reporting-issues.html:
>> - note removed
>> - all links updated
>> - replaced custom query link with JIRA Subversion project page
>>
>> What's still missing:
>> - updating the two forms (key- and keyword search)
>>
>> Unfortunately I was running out of time. If anybody wants to take it from
>> here, I'd be glad.
> This was partly addressed by my commit r1706376 and nearly everything
> else you suggest is committed in r1706908.
>
> The one part I did differently was the link to query at
> https://issues.apache.org/jira/issues/?jql=project = SVN"
>
> because I feel that gives a better starting point for searching
> SVN-specific issues than does
>
> "https://issues.apache.org/jira/browse/SVN/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel"
>
> The latter link shows a Subversion-specific overview page but the
> 'Search' box there searches within all projects by default which isn't
> quite what I want. (Maybe we can improve that in future.)
>
> - Julian
Makes complete sense to me and I agree that the starting point is better
than the one in my patch. :-)
Regards,
Stefan
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 2 October 2015 at 01:20, Stefan <lu...@posteo.de> wrote:
> On 28/09/2015 16:48, Ivan Zhakov wrote:
>>
>> On 28 September 2015 at 13:59, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>
>>> On 28 September 2015 at 13:55, Julian Foad <ju...@gmail.com> wrote:
>>>>
>>>> Luke1410 is offering (on IRC [1]) to add release dates to all the
>>>> version labels. That would greatly improve the Jira Summary page [2]
>>>> where one of the first things it attempts to show is a list of
>>>> "Versions: Unreleased" which currently looks very silly.
>>>>
>>> I'm already working on it.
>>>
>> I've added release date for all released versions and mark them as
>> 'released' in JIRA. Versions like '1.9.x', '1.9.0-conisder', 'all',
>> 'blue-sky' are still marked as unreleased, but I'm going to post about
>> them separately.
>
> Just spotted that 1.9.2 is not yet set as released:
> https://issues.apache.org/jira/browse/SVN/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
>
Fixed. But it seems 1.9.2 was added after migration because there is
no issues with Fix versions = 1.9.2
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Julian Foad <ju...@gmail.com>.
On 2 October 2015, Stefan wrote:
> On 28/09/2015 16:48, Ivan Zhakov wrote:
>> On 28 September 2015 at 13:59, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> Anyone volunteering to update 'Reporting Issues' page [1]? The
>> 'issue-tracker.html' page [2] on tigris.org could be used as template.
>>
>> [1] http://subversion.apache.org/reporting-issues.html
>> [2] http://subversion.tigris.org/issue-tracker.html
>
> Attached is a half-finished patch for reporting-issues.html:
> - note removed
> - all links updated
> - replaced custom query link with JIRA Subversion project page
>
> What's still missing:
> - updating the two forms (key- and keyword search)
>
> Unfortunately I was running out of time. If anybody wants to take it from
> here, I'd be glad.
This was partly addressed by my commit r1706376 and nearly everything
else you suggest is committed in r1706908.
The one part I did differently was the link to query at
https://issues.apache.org/jira/issues/?jql=project = SVN"
because I feel that gives a better starting point for searching
SVN-specific issues than does
"https://issues.apache.org/jira/browse/SVN/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel"
The latter link shows a Subversion-specific overview page but the
'Search' box there searches within all projects by default which isn't
quite what I want. (Maybe we can improve that in future.)
- Julian
Re: Migrating Subversion issues to ...
Posted by Stefan <lu...@posteo.de>.
On 28/09/2015 16:48, Ivan Zhakov wrote:
> On 28 September 2015 at 13:59, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 28 September 2015 at 13:55, Julian Foad <ju...@gmail.com> wrote:
>>> Luke1410 is offering (on IRC [1]) to add release dates to all the
>>> version labels. That would greatly improve the Jira Summary page [2]
>>> where one of the first things it attempts to show is a list of
>>> "Versions: Unreleased" which currently looks very silly.
>>>
>> I'm already working on it.
>>
> I've added release date for all released versions and mark them as
> 'released' in JIRA. Versions like '1.9.x', '1.9.0-conisder', 'all',
> 'blue-sky' are still marked as unreleased, but I'm going to post about
> them separately.
Just spotted that 1.9.2 is not yet set as released:
https://issues.apache.org/jira/browse/SVN/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
Regards,
Stefan
Re: Migrating Subversion issues to ...
Posted by Stefan <lu...@posteo.de>.
On 28/09/2015 16:48, Ivan Zhakov wrote:
> On 28 September 2015 at 13:59, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
>
> Anyone volunteering to update 'Reporting Issues' page [1]? The
> 'issue-tracker.html' page [2] on tigris.org could be used as template.
>
> [1] http://subversion.apache.org/reporting-issues.html
> [2] http://subversion.tigris.org/issue-tracker.html
Attached is a half-finished patch for reporting-issues.html:
- note removed
- all links updated
- replaced custom query link with JIRA Subversion project page
What's still missing:
- updating the two forms (key- and keyword search)
Unfortunately I was running out of time. If anybody wants to take it
from here, I'd be glad.
Regards,
Stefan
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 28 September 2015 at 13:59, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 28 September 2015 at 13:55, Julian Foad <ju...@gmail.com> wrote:
>> Luke1410 is offering (on IRC [1]) to add release dates to all the
>> version labels. That would greatly improve the Jira Summary page [2]
>> where one of the first things it attempts to show is a list of
>> "Versions: Unreleased" which currently looks very silly.
>>
> I'm already working on it.
>
I've added release date for all released versions and mark them as
'released' in JIRA. Versions like '1.9.x', '1.9.0-conisder', 'all',
'blue-sky' are still marked as unreleased, but I'm going to post about
them separately.
Anyone volunteering to update 'Reporting Issues' page [1]? The
'issue-tracker.html' page [2] on tigris.org could be used as template.
[1] http://subversion.apache.org/reporting-issues.html
[2] http://subversion.tigris.org/issue-tracker.html
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 28 September 2015 at 13:55, Julian Foad <ju...@gmail.com> wrote:
> Luke1410 is offering (on IRC [1]) to add release dates to all the
> version labels. That would greatly improve the Jira Summary page [2]
> where one of the first things it attempts to show is a list of
> "Versions: Unreleased" which currently looks very silly.
>
I'm already working on it.
> Bert pointed out that release dates in CHANGES file aren't all
> accurate. Email archives should contain more accurate source data. But
> that's a separate problem that we can still resolve later. Luke1410
> confirmed that dates entered against the Jira labels can still be
> edited later.
>
I think using dates from CHANGES is ok.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Julian Foad <ju...@gmail.com>.
Luke1410 is offering (on IRC [1]) to add release dates to all the
version labels. That would greatly improve the Jira Summary page [2]
where one of the first things it attempts to show is a list of
"Versions: Unreleased" which currently looks very silly.
Bert pointed out that release dates in CHANGES file aren't all
accurate. Email archives should contain more accurate source data. But
that's a separate problem that we can still resolve later. Luke1410
confirmed that dates entered against the Jira labels can still be
edited later.
Seems like a good thing to do. I say "yes please!" I suggested he
should go ahead and do it.
- Julian
[1] http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-09-28#l37
[2] https://issues.apache.org/jira/browse/SVN/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 28.09.2015 12:24, Ivan Zhakov wrote:
> On 28 September 2015 at 13:22, Branko Čibej <br...@apache.org> wrote:
>> On 28.09.2015 12:18, Ivan Zhakov wrote:
>>> On 28 September 2015 at 13:02, Branko Čibej <br...@apache.org> wrote:
>>>> On 28.09.2015 11:41, Ivan Zhakov wrote:
>>>>> On 27 September 2015 at 23:24, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>>> On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>>>>>>> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>>>>>> I think we should wait for responses until the middle of next week.
>>>>>>>>>
>>>>>>>> Sounds fine for me.
>>>>>>>>
>>>>>>>> FWIW: It's very likely that I will be very busy on next week due my
>>>>>>>> dayjob. May be I find some time for final migration or may be not. But
>>>>>>>> I definitely will be able to perform final migration on week after 27
>>>>>>>> sep (I assume that we do not discover any showstopper issues requiring
>>>>>>>> migration script changes).
>>>>>>> I have unlocked the tigris project. Someone can ping me when it should be locked again.
>>>>>>>
>>>>>> Hi Mark,
>>>>>>
>>>>>> I'm going to start migration process tomorrow morning. Could you
>>>>>> please lock tigris.org project? I think it will ok if our issue
>>>>>> tracker will read-only for day or something.
>>>>>>
>>>>>>
>>>>> Issues are finally migrated to ASF JIRA:
>>>>> https://issues.apache.org/jira/browse/SVN
>>>> Project memberships and roles have not been set up yet; I can't modify
>>>> issues even when they're assigned to me.
>>>>
>>> Should be fixed now: for some reason all PMC members was part of
>>> "Developers" role instead of "PMC".
>> Yup, works for me. But I'm surprised that a "Developer" can't modify
>> (e.g., resolve) issues assigned to her ...
>>
> "Developers" seems to be default JIRA role. ASF JIRA uses ASF specific roles:
> - Administrators
> - ASF Members
> - Committers
> - Contributors
> - PMC
>
> Btw I've added all PMC members to "PMC" group without checking for ASF
> membership.
I see. Well, I'll leave it to you to tweak whatever still need tweaking.
It's looking very good already.
-- Brane
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 28 September 2015 at 13:22, Branko Čibej <br...@apache.org> wrote:
> On 28.09.2015 12:18, Ivan Zhakov wrote:
>> On 28 September 2015 at 13:02, Branko Čibej <br...@apache.org> wrote:
>>> On 28.09.2015 11:41, Ivan Zhakov wrote:
>>>> On 27 September 2015 at 23:24, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>> On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>>>>>> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>>>>> I think we should wait for responses until the middle of next week.
>>>>>>>>
>>>>>>> Sounds fine for me.
>>>>>>>
>>>>>>> FWIW: It's very likely that I will be very busy on next week due my
>>>>>>> dayjob. May be I find some time for final migration or may be not. But
>>>>>>> I definitely will be able to perform final migration on week after 27
>>>>>>> sep (I assume that we do not discover any showstopper issues requiring
>>>>>>> migration script changes).
>>>>>> I have unlocked the tigris project. Someone can ping me when it should be locked again.
>>>>>>
>>>>> Hi Mark,
>>>>>
>>>>> I'm going to start migration process tomorrow morning. Could you
>>>>> please lock tigris.org project? I think it will ok if our issue
>>>>> tracker will read-only for day or something.
>>>>>
>>>>>
>>>> Issues are finally migrated to ASF JIRA:
>>>> https://issues.apache.org/jira/browse/SVN
>>> Project memberships and roles have not been set up yet; I can't modify
>>> issues even when they're assigned to me.
>>>
>> Should be fixed now: for some reason all PMC members was part of
>> "Developers" role instead of "PMC".
>
> Yup, works for me. But I'm surprised that a "Developer" can't modify
> (e.g., resolve) issues assigned to her ...
>
"Developers" seems to be default JIRA role. ASF JIRA uses ASF specific roles:
- Administrators
- ASF Members
- Committers
- Contributors
- PMC
Btw I've added all PMC members to "PMC" group without checking for ASF
membership.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 28.09.2015 12:18, Ivan Zhakov wrote:
> On 28 September 2015 at 13:02, Branko Čibej <br...@apache.org> wrote:
>> On 28.09.2015 11:41, Ivan Zhakov wrote:
>>> On 27 September 2015 at 23:24, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>> On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>>>>> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>>>> I think we should wait for responses until the middle of next week.
>>>>>>>
>>>>>> Sounds fine for me.
>>>>>>
>>>>>> FWIW: It's very likely that I will be very busy on next week due my
>>>>>> dayjob. May be I find some time for final migration or may be not. But
>>>>>> I definitely will be able to perform final migration on week after 27
>>>>>> sep (I assume that we do not discover any showstopper issues requiring
>>>>>> migration script changes).
>>>>> I have unlocked the tigris project. Someone can ping me when it should be locked again.
>>>>>
>>>> Hi Mark,
>>>>
>>>> I'm going to start migration process tomorrow morning. Could you
>>>> please lock tigris.org project? I think it will ok if our issue
>>>> tracker will read-only for day or something.
>>>>
>>>>
>>> Issues are finally migrated to ASF JIRA:
>>> https://issues.apache.org/jira/browse/SVN
>> Project memberships and roles have not been set up yet; I can't modify
>> issues even when they're assigned to me.
>>
> Should be fixed now: for some reason all PMC members was part of
> "Developers" role instead of "PMC".
Yup, works for me. But I'm surprised that a "Developer" can't modify
(e.g., resolve) issues assigned to her ...
-- Brane
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 28 September 2015 at 13:02, Branko Čibej <br...@apache.org> wrote:
> On 28.09.2015 11:41, Ivan Zhakov wrote:
>> On 27 September 2015 at 23:24, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>> On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>>>> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>>> I think we should wait for responses until the middle of next week.
>>>>>>
>>>>> Sounds fine for me.
>>>>>
>>>>> FWIW: It's very likely that I will be very busy on next week due my
>>>>> dayjob. May be I find some time for final migration or may be not. But
>>>>> I definitely will be able to perform final migration on week after 27
>>>>> sep (I assume that we do not discover any showstopper issues requiring
>>>>> migration script changes).
>>>>
>>>> I have unlocked the tigris project. Someone can ping me when it should be locked again.
>>>>
>>> Hi Mark,
>>>
>>> I'm going to start migration process tomorrow morning. Could you
>>> please lock tigris.org project? I think it will ok if our issue
>>> tracker will read-only for day or something.
>>>
>>>
>> Issues are finally migrated to ASF JIRA:
>> https://issues.apache.org/jira/browse/SVN
>
> Project memberships and roles have not been set up yet; I can't modify
> issues even when they're assigned to me.
>
Should be fixed now: for some reason all PMC members was part of
"Developers" role instead of "PMC".
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 28.09.2015 11:41, Ivan Zhakov wrote:
> On 27 September 2015 at 23:24, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>>> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>> I think we should wait for responses until the middle of next week.
>>>>>
>>>> Sounds fine for me.
>>>>
>>>> FWIW: It's very likely that I will be very busy on next week due my
>>>> dayjob. May be I find some time for final migration or may be not. But
>>>> I definitely will be able to perform final migration on week after 27
>>>> sep (I assume that we do not discover any showstopper issues requiring
>>>> migration script changes).
>>>
>>> I have unlocked the tigris project. Someone can ping me when it should be locked again.
>>>
>> Hi Mark,
>>
>> I'm going to start migration process tomorrow morning. Could you
>> please lock tigris.org project? I think it will ok if our issue
>> tracker will read-only for day or something.
>>
>>
> Issues are finally migrated to ASF JIRA:
> https://issues.apache.org/jira/browse/SVN
Project memberships and roles have not been set up yet; I can't modify
issues even when they're assigned to me.
-- Brane
Re: Migrating Subversion issues to ...
Posted by Erik Huelsmann <eh...@gmail.com>.
> > Hi Mark,
> >
> > I'm going to start migration process tomorrow morning. Could you
> > please lock tigris.org project? I think it will ok if our issue
> > tracker will read-only for day or something.
> >
> >
> Issues are finally migrated to ASF JIRA:
> https://issues.apache.org/jira/browse/SVN
>
>
Great! Thanks so much!
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Re: Migrating Subversion issues to ...
Posted by Stefan Hett <st...@egosoft.com>.
On 9/28/2015 11:41 AM, Ivan Zhakov wrote:
> On 27 September 2015 at 23:24, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>>> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>>> I think we should wait for responses until the middle of next week.
>>>>>
>>>> Sounds fine for me.
>>>>
>>>> FWIW: It's very likely that I will be very busy on next week due my
>>>> dayjob. May be I find some time for final migration or may be not. But
>>>> I definitely will be able to perform final migration on week after 27
>>>> sep (I assume that we do not discover any showstopper issues requiring
>>>> migration script changes).
>>>
>>> I have unlocked the tigris project. Someone can ping me when it should be locked again.
>>>
>> Hi Mark,
>>
>> I'm going to start migration process tomorrow morning. Could you
>> please lock tigris.org project? I think it will ok if our issue
>> tracker will read-only for day or something.
>>
>>
> Issues are finally migrated to ASF JIRA:
> https://issues.apache.org/jira/browse/SVN
>
Great work Ivan. :-)
--
Regards,
Stefan Hett
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 27 September 2015 at 23:24, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>>
>> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>
>>> >
>>> > I think we should wait for responses until the middle of next week.
>>> >
>>> Sounds fine for me.
>>>
>>> FWIW: It's very likely that I will be very busy on next week due my
>>> dayjob. May be I find some time for final migration or may be not. But
>>> I definitely will be able to perform final migration on week after 27
>>> sep (I assume that we do not discover any showstopper issues requiring
>>> migration script changes).
>>
>>
>> I have unlocked the tigris project. Someone can ping me when it should be locked again.
>>
> Hi Mark,
>
> I'm going to start migration process tomorrow morning. Could you
> please lock tigris.org project? I think it will ok if our issue
> tracker will read-only for day or something.
>
>
Issues are finally migrated to ASF JIRA:
https://issues.apache.org/jira/browse/SVN
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
Ok, it is now locked.
Thanks for doing the migration.
Mark
Sent from my iPhone
> On Sep 27, 2015, at 4:24 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
>> On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>>
>>> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>
>>>>
>>>> I think we should wait for responses until the middle of next week.
>>> Sounds fine for me.
>>>
>>> FWIW: It's very likely that I will be very busy on next week due my
>>> dayjob. May be I find some time for final migration or may be not. But
>>> I definitely will be able to perform final migration on week after 27
>>> sep (I assume that we do not discover any showstopper issues requiring
>>> migration script changes).
>>
>>
>> I have unlocked the tigris project. Someone can ping me when it should be locked again.
> Hi Mark,
>
> I'm going to start migration process tomorrow morning. Could you
> please lock tigris.org project? I think it will ok if our issue
> tracker will read-only for day or something.
>
>
> --
> Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 18 September 2015 at 17:53, Mark Phippard <ma...@gmail.com> wrote:
>
> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> >
>> > I think we should wait for responses until the middle of next week.
>> >
>> Sounds fine for me.
>>
>> FWIW: It's very likely that I will be very busy on next week due my
>> dayjob. May be I find some time for final migration or may be not. But
>> I definitely will be able to perform final migration on week after 27
>> sep (I assume that we do not discover any showstopper issues requiring
>> migration script changes).
>
>
> I have unlocked the tigris project. Someone can ping me when it should be locked again.
>
Hi Mark,
I'm going to start migration process tomorrow morning. Could you
please lock tigris.org project? I think it will ok if our issue
tracker will read-only for day or something.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Sep 18, 2015 at 10:56 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 18 September 2015 at 16:53, Mark Phippard <ma...@gmail.com> wrote:
> > On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com>
> wrote:
> >>
> >> >
> >> > I think we should wait for responses until the middle of next week.
> >> >
> >> Sounds fine for me.
> >>
> >> FWIW: It's very likely that I will be very busy on next week due my
> >> dayjob. May be I find some time for final migration or may be not. But
> >> I definitely will be able to perform final migration on week after 27
> >> sep (I assume that we do not discover any showstopper issues requiring
> >> migration script changes).
> >
> >
> > I have unlocked the tigris project. Someone can ping me when it should
> be
> > locked again.
> >
> May be we can put issue tracker on tigris read-only: in this case I
> could prepare everything today to avoid potential surprises and the
> time of final migration. Any opinions?
>
>
The only way to make issue tracker read-only is to lock the project. Given
that issue tracker is the only tool, not really a big deal. I just assumed
we did not want the issue tracker read-only if it is going to be another
week until we migrate it.
Just tell me when we want the project locked, today .. next week. I can do
whatever we want.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 18 September 2015 at 16:53, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> >
>> > I think we should wait for responses until the middle of next week.
>> >
>> Sounds fine for me.
>>
>> FWIW: It's very likely that I will be very busy on next week due my
>> dayjob. May be I find some time for final migration or may be not. But
>> I definitely will be able to perform final migration on week after 27
>> sep (I assume that we do not discover any showstopper issues requiring
>> migration script changes).
>
>
> I have unlocked the tigris project. Someone can ping me when it should be
> locked again.
>
May be we can put issue tracker on tigris read-only: in this case I
could prepare everything today to avoid potential surprises and the
time of final migration. Any opinions?
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Sep 18, 2015 at 10:49 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> >
> > I think we should wait for responses until the middle of next week.
> >
> Sounds fine for me.
>
> FWIW: It's very likely that I will be very busy on next week due my
> dayjob. May be I find some time for final migration or may be not. But
> I definitely will be able to perform final migration on week after 27
> sep (I assume that we do not discover any showstopper issues requiring
> migration script changes).
>
I have unlocked the tigris project. Someone can ping me when it should be
locked again.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 18 September 2015 at 16:25, Branko Čibej <br...@apache.org> wrote:
> On 18 Sep 2015 4:16 pm, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>>
>> On 18 September 2015 at 16:10, Stefan Sperling <st...@elego.de> wrote:
>> > On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
>> >> Attachments was successfully migrated after multiple attempts and help
>> >> from ASF Infra team. This how Subversion issue tracker will look like:
>> >> https://issues.apache.org/jira/browse/SVN
>> >>
>> >> I'm ready to perform final migration, but I think we should make issue
>> >> tracker on tigris.org read only. It also would nice finalize tigris ->
>> >> asf user name mappings, at least for most referenced users.
>> >
>> > +1
>> >
>> > Please migrate ASAP.
>> Currently I'm waiting for tigris -> asf user mapping mails to @tigris
>> addresses.
>
> I've begun sending the mails, from my ASF account. I decided to send
> separate mails to each address, to avoid triggering spam filters as much as
> possible. I'm allowing lots of time between the mails so that I don't get
> accidentally blacklisted by the mail relay.
>
> I think we should wait for responses until the middle of next week.
>
Sounds fine for me.
FWIW: It's very likely that I will be very busy on next week due my
dayjob. May be I find some time for final migration or may be not. But
I definitely will be able to perform final migration on week after 27
sep (I assume that we do not discover any showstopper issues requiring
migration script changes).
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 18.09.2015 16:25, Branko Čibej wrote:
> On 18 Sep 2015 4:16 pm, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>> On 18 September 2015 at 16:10, Stefan Sperling <st...@elego.de> wrote:
>>> On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
>>>> Attachments was successfully migrated after multiple attempts and help
>>>> from ASF Infra team. This how Subversion issue tracker will look like:
>>>> https://issues.apache.org/jira/browse/SVN
>>>>
>>>> I'm ready to perform final migration, but I think we should make issue
>>>> tracker on tigris.org read only. It also would nice finalize tigris ->
>>>> asf user name mappings, at least for most referenced users.
>>> +1
>>>
>>> Please migrate ASAP.
>> Currently I'm waiting for tigris -> asf user mapping mails to @tigris
> addresses.
>
> I've begun sending the mails, from my ASF account. I decided to send
> separate mails to each address, to avoid triggering spam filters as much as
> possible. I'm allowing lots of time between the mails so that I don't get
> accidentally blacklisted by the mail relay.
>
> I think we should wait for responses until the middle of next week.
All the 1123 mails have been sent now. 205 of them bounced (the bounces
seem to be equally distributed regardless of the number of comments made
by the author).
-- Brane
Re: Migrating Subversion issues to ...
Posted by Branko Čibej <br...@apache.org>.
On 18 Sep 2015 4:16 pm, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>
> On 18 September 2015 at 16:10, Stefan Sperling <st...@elego.de> wrote:
> > On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
> >> Attachments was successfully migrated after multiple attempts and help
> >> from ASF Infra team. This how Subversion issue tracker will look like:
> >> https://issues.apache.org/jira/browse/SVN
> >>
> >> I'm ready to perform final migration, but I think we should make issue
> >> tracker on tigris.org read only. It also would nice finalize tigris ->
> >> asf user name mappings, at least for most referenced users.
> >
> > +1
> >
> > Please migrate ASAP.
> Currently I'm waiting for tigris -> asf user mapping mails to @tigris
addresses.
I've begun sending the mails, from my ASF account. I decided to send
separate mails to each address, to avoid triggering spam filters as much as
possible. I'm allowing lots of time between the mails so that I don't get
accidentally blacklisted by the mail relay.
I think we should wait for responses until the middle of next week.
-- Brane
Re: Migrating Subversion issues to ...
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 18, 2015 at 04:16:22PM +0200, Ivan Zhakov wrote:
> Currently I'm waiting for tigris -> asf user mapping mails to @tigris addresses.
I would say we shouldn't wait for that if it means you can't finish the
migration before you're back home and bound up in $dayjob activities.
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 18 September 2015 at 16:10, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
>> Attachments was successfully migrated after multiple attempts and help
>> from ASF Infra team. This how Subversion issue tracker will look like:
>> https://issues.apache.org/jira/browse/SVN
>>
>> I'm ready to perform final migration, but I think we should make issue
>> tracker on tigris.org read only. It also would nice finalize tigris ->
>> asf user name mappings, at least for most referenced users.
>
> +1
>
> Please migrate ASAP.
Currently I'm waiting for tigris -> asf user mapping mails to @tigris addresses.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
> Attachments was successfully migrated after multiple attempts and help
> from ASF Infra team. This how Subversion issue tracker will look like:
> https://issues.apache.org/jira/browse/SVN
>
> I'm ready to perform final migration, but I think we should make issue
> tracker on tigris.org read only. It also would nice finalize tigris ->
> asf user name mappings, at least for most referenced users.
+1
Please migrate ASAP.
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Sep 18, 2015 at 9:47 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
I'm ready to perform final migration, but I think we should make issue
> tracker on tigris.org read only. It also would nice finalize tigris ->
> asf user name mappings, at least for most referenced users.
>
Just as a an fyi ..
The way tigris.org is configured as a community site there are global roles
that give people read/write access to the issue tracker for all public
projects. C-Mike and I tried, but we cannot revoke this for just the
Subversion project. So what I did was lock the project. That makes the
whole project read-only for all users. I cannot think of any reason not to
do this anyway.
Other things we could do would be to remove all users, except us, from the
project membership. I think people can add themselves back, though that
might be configurable to the point that we would have to approve it.
For now, I have just left the project locked.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 18 September 2015 at 14:37, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 16 September 2015 at 14:44, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 15 September 2015 at 22:20, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>> On 15 September 2015 at 20:02, Greg Stein <gs...@gmail.com> wrote:
>>>> You can do it. File an INFRA ticket for porting our issues into JIRA, and
>>>> note that you have some content for a test load. They do test loads often
>>>> for incoming, so they have a runbook for that.
>>>>
>>>> (and post the INFRA ticket here, so others can Watch the ticket if they
>>>> like)
>>>>
>>> Done:
>>> https://issues.apache.org/jira/browse/INFRA-10439
>>>
>> Just to keep everyone updated: ASF Infra team performed first test
>> migration for us:
>> https://issues.apache.org/jira/browse/SVN
>>
>
> Status update:
>
>> Please report me any problems or suggestions. Current TODO list:
>> - Migrate attachments [IN PROGRESS]
> Some attachments was successfully migrated, but some didn't. I
> provided probably fixed import data to INFRA team and waiting for fix
> round of test migration.
>
Attachments was successfully migrated after multiple attempts and help
from ASF Infra team. This how Subversion issue tracker will look like:
https://issues.apache.org/jira/browse/SVN
I'm ready to perform final migration, but I think we should make issue
tracker on tigris.org read only. It also would nice finalize tigris ->
asf user name mappings, at least for most referenced users.
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Sep 18, 2015 at 10:33 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 18 September 2015 at 15:06, <be...@qqmail.nl> wrote:
>> I created accounts ‘sussman’ and ‘pburba’ on Jira and e-mailed Ben and Paul
>> about them.
>>
> I've added user mapping for 'sussman' and 'pburba' to migration
> script, even though I'm not sure that it's a good idea to register
> account for someone else.
No concerns about that on my front, I've been out of the email loop
the past 3 weeks anyway.
> --
> Ivan Zhakov
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 18 September 2015 at 15:06, <be...@qqmail.nl> wrote:
> I created accounts ‘sussman’ and ‘pburba’ on Jira and e-mailed Ben and Paul
> about them.
>
I've added user mapping for 'sussman' and 'pburba' to migration
script, even though I'm not sure that it's a good idea to register
account for someone else.
--
Ivan Zhakov
RE: Migrating Subversion issues to ...
Posted by be...@qqmail.nl.
I created accounts ‘sussman’ and ‘pburba’ on Jira and e-mailed Ben and Paul about them.
Bert
From: Ivan Zhakov
Sent: vrijdag 18 september 2015 14:38
To: Greg Stein
Cc: Subversion Development
Subject: Re: Migrating Subversion issues to ...
On 16 September 2015 at 14:44, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 15 September 2015 at 22:20, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 15 September 2015 at 20:02, Greg Stein <gs...@gmail.com> wrote:
>>> You can do it. File an INFRA ticket for porting our issues into JIRA, and
>>> note that you have some content for a test load. They do test loads often
>>> for incoming, so they have a runbook for that.
>>>
>>> (and post the INFRA ticket here, so others can Watch the ticket if they
>>> like)
>>>
>> Done:
>> https://issues.apache.org/jira/browse/INFRA-10439
>>
> Just to keep everyone updated: ASF Infra team performed first test
> migration for us:
> https://issues.apache.org/jira/browse/SVN
>
Status update:
> Please report me any problems or suggestions. Current TODO list:
> - Migrate attachments [IN PROGRESS]
Some attachments was successfully migrated, but some didn't. I
provided probably fixed import data to INFRA team and waiting for fix
round of test migration.
> - Preserve history of changes [DONE]
- Migrate URL field [DONE]
- Timezones issue should be fixed, anyway I'm not going to spend more
time on them ;)
- I decided migrate issues with {noformat} tag around comments and
description to keep issues looking the same as in tigris.org. We can
use normal JIRA syntax for new issues and edit old one when needed.
Remaining issue:
- Ask tigris.org users to provide their ASF usernames, otherwise their
issues will be imported as "Subversion Importer" user with "Original
reported by username" text. See attached file of currently unmapped
users and references count. As far I know Branko is working on this.
- Daniel suggested migrate "status whiteboard" field [1]. I want just
drop it since we don't have such field in default JIRA configuration.
Adding custom field would be overkill IMHO. So please object early if
you have different opinion on this.
[1] http://subversion.tigris.org/issues/buglist.cgi?status_whiteboard=.&status_whiteboard_type=regexp
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 16 September 2015 at 14:44, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 15 September 2015 at 22:20, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On 15 September 2015 at 20:02, Greg Stein <gs...@gmail.com> wrote:
>>> You can do it. File an INFRA ticket for porting our issues into JIRA, and
>>> note that you have some content for a test load. They do test loads often
>>> for incoming, so they have a runbook for that.
>>>
>>> (and post the INFRA ticket here, so others can Watch the ticket if they
>>> like)
>>>
>> Done:
>> https://issues.apache.org/jira/browse/INFRA-10439
>>
> Just to keep everyone updated: ASF Infra team performed first test
> migration for us:
> https://issues.apache.org/jira/browse/SVN
>
Status update:
> Please report me any problems or suggestions. Current TODO list:
> - Migrate attachments [IN PROGRESS]
Some attachments was successfully migrated, but some didn't. I
provided probably fixed import data to INFRA team and waiting for fix
round of test migration.
> - Preserve history of changes [DONE]
- Migrate URL field [DONE]
- Timezones issue should be fixed, anyway I'm not going to spend more
time on them ;)
- I decided migrate issues with {noformat} tag around comments and
description to keep issues looking the same as in tigris.org. We can
use normal JIRA syntax for new issues and edit old one when needed.
Remaining issue:
- Ask tigris.org users to provide their ASF usernames, otherwise their
issues will be imported as "Subversion Importer" user with "Original
reported by username" text. See attached file of currently unmapped
users and references count. As far I know Branko is working on this.
- Daniel suggested migrate "status whiteboard" field [1]. I want just
drop it since we don't have such field in default JIRA configuration.
Adding custom field would be overkill IMHO. So please object early if
you have different opinion on this.
[1] http://subversion.tigris.org/issues/buglist.cgi?status_whiteboard=.&status_whiteboard_type=regexp
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 15 September 2015 at 22:20, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 15 September 2015 at 20:02, Greg Stein <gs...@gmail.com> wrote:
>> You can do it. File an INFRA ticket for porting our issues into JIRA, and
>> note that you have some content for a test load. They do test loads often
>> for incoming, so they have a runbook for that.
>>
>> (and post the INFRA ticket here, so others can Watch the ticket if they
>> like)
>>
> Done:
> https://issues.apache.org/jira/browse/INFRA-10439
>
Just to keep everyone updated: ASF Infra team performed first test
migration for us:
https://issues.apache.org/jira/browse/SVN
Please report me any problems or suggestions. Current TODO list:
- Migrate attachments
- Preserve history of changes
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 15 September 2015 at 20:02, Greg Stein <gs...@gmail.com> wrote:
> You can do it. File an INFRA ticket for porting our issues into JIRA, and
> note that you have some content for a test load. They do test loads often
> for incoming, so they have a runbook for that.
>
> (and post the INFRA ticket here, so others can Watch the ticket if they
> like)
>
Done:
https://issues.apache.org/jira/browse/INFRA-10439
(I don't know why issue was created without description)
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Greg Stein <gs...@gmail.com>.
You can do it. File an INFRA ticket for porting our issues into JIRA, and
note that you have some content for a test load. They do test loads often
for incoming, so they have a runbook for that.
(and post the INFRA ticket here, so others can Watch the ticket if they
like)
Cheers,
-g
On Tue, Sep 15, 2015 at 9:51 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 15 September 2015 at 14:40, Mark Phippard <ma...@gmail.com> wrote:
> > On Tue, Sep 15, 2015 at 5:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
> >>
> >> Hi All,
> >>
> >>
> >>
> >> Here at the hackathon in Berlin we are discussing issue trackers, and
> more
> >> particular how we should eventually move our issues to ASF
> infrastructure.
> >> An old TODO.
> >>
> >>
> >>
> >> Ivan just converted the data of the much smaller Serf issuetracker to
> Jira
> >> for the Apache Serf project, and he offers to perform the migration for
> >> Subversion too.
> >>
> >>
> >>
> >>
> >>
> >> I think we really have 3 options:
> >>
> >> [ ] Keep our issues on Tigris
> >>
> >> [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
> >>
> >> [ ] Migrate to the standard ASF Jira installation
> >>
> >>
> >>
> >> In Jira we can keep our existing issuenumbers, while for Bugzilla we
> would
> >> need a separate instance.
> >>
> >>
> >>
> >> Personally I would choose the third option if we aim to keep as much
> >> history as possible (including ascii art and attachments) available
> after
> >> the migration. The information in our issue database is just too
> valuable to
> >> lose…. Even if it will take a few more years to get there.
> >>
> >>
> >>
> >> Bert
> >
> >
> > +1 on migration.
> >
> > I would bias the decision in favor of doing the migration over trying to
> > solve every problem and letting another year go by.
> >
> > If Ivan has a working migration for Jira then +1 for that.
> >
> > I think it is a mistake to get hung up on these other issues that are
> > trivial in my opinion. Monospace vs proportional -- I do not believe
> anyone
> > really cares. Just let the ascii art get messed up. Old links not
> working
> > ... not a problem you can solve. Just move on.
> >
> > I would just migrate the data to Jira, not try to solve all these
> problems
> > and move forward. I have seen zero evidence in the years I have been
> > involved in this project that anyone really cares about the issue
> tracker.
> > We go out of our way to actively discourage people from using it. To bog
> > down on migration over relatively small problems would just be a waste of
> > time and effort. It sounds like you already will be accomplishing a lot
> by
> > keeping issue numbers roughly the same.
> >
> > Take that victory and get this done.
> >
> It seems people generally support idea to move to ASF JIRA. I already
> have some data converted and want to perform *test* import to ASF
> JIRA. Just to see how it will like. Should I request ASF INFRA team do
> this for us or such request supposed to be created by PMC chair?
>
> --
> Ivan Zhakov
>
Re: Migrating Subversion issues to ...
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 15 September 2015 at 14:40, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, Sep 15, 2015 at 5:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
>>
>> Hi All,
>>
>>
>>
>> Here at the hackathon in Berlin we are discussing issue trackers, and more
>> particular how we should eventually move our issues to ASF infrastructure.
>> An old TODO.
>>
>>
>>
>> Ivan just converted the data of the much smaller Serf issuetracker to Jira
>> for the Apache Serf project, and he offers to perform the migration for
>> Subversion too.
>>
>>
>>
>>
>>
>> I think we really have 3 options:
>>
>> [ ] Keep our issues on Tigris
>>
>> [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>>
>> [ ] Migrate to the standard ASF Jira installation
>>
>>
>>
>> In Jira we can keep our existing issuenumbers, while for Bugzilla we would
>> need a separate instance.
>>
>>
>>
>> Personally I would choose the third option if we aim to keep as much
>> history as possible (including ascii art and attachments) available after
>> the migration. The information in our issue database is just too valuable to
>> lose…. Even if it will take a few more years to get there.
>>
>>
>>
>> Bert
>
>
> +1 on migration.
>
> I would bias the decision in favor of doing the migration over trying to
> solve every problem and letting another year go by.
>
> If Ivan has a working migration for Jira then +1 for that.
>
> I think it is a mistake to get hung up on these other issues that are
> trivial in my opinion. Monospace vs proportional -- I do not believe anyone
> really cares. Just let the ascii art get messed up. Old links not working
> ... not a problem you can solve. Just move on.
>
> I would just migrate the data to Jira, not try to solve all these problems
> and move forward. I have seen zero evidence in the years I have been
> involved in this project that anyone really cares about the issue tracker.
> We go out of our way to actively discourage people from using it. To bog
> down on migration over relatively small problems would just be a waste of
> time and effort. It sounds like you already will be accomplishing a lot by
> keeping issue numbers roughly the same.
>
> Take that victory and get this done.
>
It seems people generally support idea to move to ASF JIRA. I already
have some data converted and want to perform *test* import to ASF
JIRA. Just to see how it will like. Should I request ASF INFRA team do
this for us or such request supposed to be created by PMC chair?
--
Ivan Zhakov
Re: Migrating Subversion issues to ...
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 15, 2015 at 5:59 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Hi All,
>
>
>
> Here at the hackathon in Berlin we are discussing issue trackers, and more
> particular how we should eventually move our issues to ASF infrastructure.
> An old TODO.
>
>
>
> Ivan just converted the data of the much smaller Serf issuetracker to Jira
> for the Apache Serf project, and he offers to perform the migration for
> Subversion too.
>
>
>
>
>
> I think we really have 3 options:
>
> [ ] Keep our issues on Tigris
>
> [ ] Migrate our issues to a new Bugzilla instance hosted by ASF infra
>
> [ ] Migrate to the standard ASF Jira installation
>
>
>
> In Jira we can keep our existing issuenumbers, while for Bugzilla we would
> need a separate instance.
>
>
>
> Personally I would choose the third option if we aim to keep as much
> history as possible (including ascii art and attachments) available after
> the migration. The information in our issue database is just too valuable
> to lose…. Even if it will take a few more years to get there.
>
>
>
> Bert
>
+1 on migration.
I would bias the decision in favor of doing the migration over trying to
solve every problem and letting another year go by.
If Ivan has a working migration for Jira then +1 for that.
I think it is a mistake to get hung up on these other issues that are
trivial in my opinion. Monospace vs proportional -- I do not believe
anyone really cares. Just let the ascii art get messed up. Old links not
working ... not a problem you can solve. Just move on.
I would just migrate the data to Jira, not try to solve all these problems
and move forward. I have seen zero evidence in the years I have been
involved in this project that anyone really cares about the issue tracker.
We go out of our way to actively discourage people from using it. To bog
down on migration over relatively small problems would just be a waste of
time and effort. It sounds like you already will be accomplishing a lot by
keeping issue numbers roughly the same.
Take that victory and get this done.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/