cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: Bug tracker: Re: [DISCUSS] - A must do tasks for the coming 1-2 months
Date Tue, 14 Aug 2012 16:12:27 GMT
On Tue, Aug 14, 2012 at 12:09 PM, David Nalley <> wrote:
> On Mon, Aug 13, 2012 at 5:18 PM, David Nalley <> wrote:
>> On Tue, Jul 31, 2012 at 2:08 PM, David Nalley <> wrote:
>>> On Mon, Jul 30, 2012 at 4:45 PM, Mohammad Nour El-Din <>
>>>> 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 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 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 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

One more thing. Since this doesn't look like it locks us in to either
side of this equation irreversibly, if someone doesn't object in the
next 5-6 hours my intention is to request the above. Let me know if
this irks anyone.


View raw message