On Tue, Aug 14, 2012 at 12:09 PM, David Nalley <da...@gnsa.us> wrote: > On Mon, Aug 13, 2012 at 5:18 PM, David Nalley <da...@gnsa.us> wrote: >> On Tue, Jul 31, 2012 at 2:08 PM, David Nalley <da...@gnsa.us> wrote: >>> On Mon, Jul 30, 2012 at 4:45 PM, Mohammad Nour El-Din <mn...@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
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. --David
