apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aniruddha Thombare <anirud...@datatorrent.com>
Subject Re: Apex ASF JIRA Migration
Date Thu, 10 Sep 2015 15:31:45 GMT
+1 for history option 3.
On Sep 10, 2015 8:52 PM, "Pramod Immaneni" <pramod@datatorrent.com> wrote:

> I would like to add +1 for 3.
>
> Thanks
>
> > On Sep 9, 2015, at 11:02 PM, Chris Nauroth <cnauroth@hortonworks.com>
> wrote:
> >
> > Hello Apex devs,
> >
> > I'd like to share some new information about the ASF JIRA migration,
> > tracked in issue INFRA-10145.
> >
> > https://issues.apache.org/jira/browse/INFRA-10145
> >
> > First, I'd like to take this opportunity to make sure the whole Apex
> > community knows that there are multiple means of contacting the Apache
> > infrastructure engineers.  This is documented here.
> >
> > http://www.apache.org/dev/infra-contact
> >
> > My experience has always been that the infrastructure team is responsive,
> > helpful and friendly.  Please feel free to contact them if necessary.  I
> > typically start by filing an INFRA issue in JIRA, and then follow up in
> > the HipChat channel if there is no response in JIRA after a few days.
> >
> > I checked in at the HipChat channel today about our JIRA migration
> status.
> > Gavin, who is handling INFRA-10145 for us, was not available, but the
> > other infrastructure engineers pointed out a few challenges.  The version
> > of JIRA in use hosted at Atlassian is different from the version
> currently
> > running in Apache.  In order to do an import, the versions must match
> > exactly, so our import actually would trigger an upgrade of ASF JIRA.
> > This would require planned downtime with at least 72 hours notice.  After
> > that, there would be some challenges with making sure imported data
> aligns
> > with best practices used in ASF JIRA, such as using roles instead of
> > groups.  Considering all of this, the infrastructure team's experience is
> > that imports take a long time, even in the best case.
> >
> > The infrastructure team and I discussed a few options for moving ahead.
> >
> > 1. Do not migrate to ASF JIRA.  The infrastructure team noted that there
> > is nothing in the incubation process that mandates moving off of your
> > Atlassian hosted instance.  I had not been aware of this.
> >
> > 2. Move to ASF JIRA, but skip the import, and start with a clean slate.
> >
> > 3. Move to ASF JIRA now, but allow the import activity to continue in the
> > background.  Once we start using ASF JIRA though, imported issues would
> > not be able to land in the same project key.  They'd likely have to
> remain
> > under the old project keys used at the Atlassian instance.
> >
> > 4. Keep waiting for the migration with the understanding that it will
> take
> > time to complete.
> >
> > I'd like to gauge the Apex community's opinion on how to proceed.  My own
> > opinion is that it would be beneficial to move to ASF JIRA, so I'd prefer
> > to rule out option 1.  One of the benefits of Apex is its integration
> with
> > numerous other Apache projects, and it can be useful to share the same
> > JIRA instance with those other projects.  For example, if you trace the
> > root cause of an Apex issue into HDFS, and you want to contact an HDFS
> > engineer, you can ask me for feedback by entering @cnauroth on a comment.
> > If you remain in the Atlassian instance, it's not guaranteed that
> > contributors on other Apache projects will have an account there.  If the
> > issue is confirmed as an HDFS bug, you can then link your Apex issue to
> > the corresponding HDFS issue for easy navigation.  I don't believe this
> > would work as cleanly in the Atlassian instance.
> >
> > My preference is option 2 for simplicity.  However, this has the side
> > effect of discarding past history.  Does the Apex community consider the
> > past history to be important?  Is it important enough to preserve the
> past
> > history that you're willing to wait longer for a migration?
> >
> > Please let me know your thoughts.
> >
> > --Chris Nauroth
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message