That would be good if you have time Ryan. I am in the process of creating my own local Ubuntu VM with version 0.4 installed so that I can test out the upgrade steps myself.
Cheers John On 27 Jan 2015 07:52, "Ryan J Ollos" <[email protected]> wrote: > On Mon, Jan 26, 2015 at 3:35 PM, Branko Čibej <[email protected]> wrote: > > > On 26.01.2015 22:03, John Chambers wrote: > > > As some of you may know I have recently taken an interest in the > > > infrastructure side of the project. > > > The following have be highlighted to me as the main priorities at the > > > moment: > > > > > > 1. Ensuring the demo servers are online. > > > 2. Re-enabling source browsing > > > 3. Upgrading i.a.o to version 0.8 from 0.4 > > > 4. Dealing with spam tickets. > > > 5. Dealing with robot users. > > > 6. Setup multi product on i.a.o. > > > > > > I know there will be issues migrating tickets from a single to multi > > > product setup so I am proposing to create a new installation of > > bloodhound > > > at version 0.8 that will have multiple products defined. Migrating the > > wiki > > > content but leave the majority of the tickets in the old instance. > Which > > > will still be available for reference. > > > > > > We can then start afresh in a multi product setup. The new instance > will > > > have all the relevant plugins to prevent spam / robot users etc. And > will > > > be easier to maintain and upgrade. > > > > > > Let me know what you think. > > > > Sounds like a plan. FWIW, it really shouldn't be too hard to migrate the > > issues from an old, non-multi-product database to the new, multi-product > > setup, while maintaining product-specific issue numbers. > > > > Yeah, it would be more ideal if we could migrate over the issues as well. I > don't think we have the exact steps documented anywhere, and perhaps it's > so trivial that the steps don't need to be documented, but I'm not counting > on it. I could spend some time this weekend testing locally with a copy of > the database. Whichever way we go with i.a.o, it would be good for us to > understand the steps required to migrate older installations to > multiproduct, and document if needed, so any time spent wouldn't be wasted. > > > > We can still get the old issue URLs to work by adding some smart rewrite > > rules to the HTTPd configuration. > > > > -- Brane > > > > >
