incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: Bug tracker: Re: [DISCUSS] - A must do tasks for the coming 1-2 months
Date Tue, 14 Aug 2012 16:09:18 GMT
On Mon, Aug 13, 2012 at 5:18 PM, David Nalley <david@gnsa.us> wrote:
> On Tue, Jul 31, 2012 at 2:08 PM, David Nalley <david@gnsa.us> wrote:
>> On Mon, Jul 30, 2012 at 4:45 PM, Mohammad Nour El-Din <mnour@apache.org> wrote:
>>> Hi...
>>>
>>>    I was talking to David Nalley over IRC and we spotted two main tasks
>>> that we should put our focus on in the coming 1-2 months and
>>> more preferably the coming month:
>>>
>>> 1- Finishing the INFRA related tasks (namely JIRA)
>>> 2- Getting our first release out
>>>
>>> With these tasks done, provided that we are gaining new committers I
>>> believe we can speed up our graduation time, more specifically when we
>>> master the release process
>>>
>>> Thoughts/Feedback?
>>>
>>
>>
>> So I am working actively on the Jira piece - the big problem is that
>> the existing Jira instance contains log files and other items with
>> customer information. My goal is to spend time this week to try a
>> couple of solutions to split the benign data from the customer data to
>> produce a working export for us to use.
>>
>> On the release bits, we've still got lots of work to do, see my
>> earlier emails today for other things that perhaps can be done there.
>>
>> --David
>
> It's been almost two weeks, so I am back to report again.
>
> I want to start with a little retrospect:
>
> The bug tracker at bugs.cloudstack.org has around 16000 bugs in it.
> Of that around 10,000 are 'public' in that all components of the bug
> are public - no private comments, no private log files, etc. (by
> private I mean customer data of either Cloud.com or Citrix)
> I've spent considerable amounts of the past two weeks working on this
> issue, and while I am closer to finishing, it's still a frustrating
> experience. Bugs continued to be added, which means the copy of the
> database/attachments that I have now has aged by two weeks, so state
> isn't syncronized, etc. What is really needed is a
>
> In truth I am beginning to doubt the efficacy of this migration, and
> figured I'd toss my ideas out here for others to consider, and I have
> a possible compromise to propose.
>
> The idea behind the migration was to preserve the existing bug data,
> particularly since so many commits reference it.
>
> However, my experience has been that the migration wouldn't preserve
> the bug numbers. Not to mention user data, etc, plus we already are
> losing around 1/3 of the bugs to begin with.
> In addition, I think that the fact that the heaviest user of bugs.cs.o
> is CloudPlatform means that this has actually become a CloudPlatform
> bug tracker more than anything else, and we've seen some frustration
> around that as well.
>
> So my thoughts are:
>
> We should abandon thoughts of migration, and start from scratch on the
> ASF's bug tracker.
> We'll redirect bugs.cloudstack.org to the ASF's jira instance.
> We should leave the existing jira instance as it is. (Citrix will be
> migrating either to a new instance as part of the migration plan
> already), and available for reference purposes in a read only state.
>
> Thoughts, comments, flames?
>
> --David



I thought I'd follow up on this discussion just a bit. I spent some
time talking to Tony Stevenson in #asfinfra about our dilemna, and may
have come upon another compromise that is even better long term.

So creating a blank slate doesn't necessarily inhibit us from
importing at a later time. There are several risk points to mitigate.
The big one being the key name space - they can't be identical. We
also need to have the same components in one as in the other. We will
potentially have some user overlap that will also have to be solved.
Following that, we have to match versions (and there is an upgrade at
the ASF on the horizon), and given the size of our import, they expect
us to do all of the upfront work on migration in their test instance,
which is perfectly reasonable.

So I rambled all through that to say: I think the ideal solution is to
delay the migration til post-release, ask for a fresh project to be
created now. This gives us a place to work on release bugs in the
interim without the overhead of having to do the migration first. And
we work on migrating the old content after that point. If we do this
my intention is still to use my two week old snapshot - and I am
operating on the assumption that everything created at bugs.cs.o is a
CCP bug going forward.

Thoughts, comments, flames?

--David

Mime
View raw message