David Kastrup wrote Thursday, August 20, 2015 10:37 AM Subject: Re: Migrating the Issues DB from Google Code to Savannah
> "Trevor Daniels" <t.dani...@treda.co.uk> writes: > >> I suggest doing the final countdown, and then stop updating the issues >> DB other than recording the resulting pushes. I'll start the final >> import of the DB to SF on Wed 26 Aug 2015. It may take some days to >> succeed, depending on load, so we should assume we have no tracker >> available for the whole of w/b 24 Aug 2015. >> >> Until it works everyone will have to either stop work or preserve >> details of their changes for the Issue DB ready to upload once we have >> a working tracker again. > > I suggest using git send-email --compose -v[version] for sending > proposed patch series to the bug mailing list, using the cover letter to > indicate the information usually marked in the bug tracker, namely type > of patch and any additional notes. The bug squad will need to note and put newly reported issues on ice, ready to be added once a tracker is available again. > In order to avoid duplication, the assignment of issue numbers and > tracking of open issue state would fall back to the patch meister. > Basically, James would have to check what patch series have been posted > to the list, assign issue numbers and states to them and post his > summaries including a reference to the respective message (message id > and/or an HTTP link to an archive) of the current patch. To make it easier for James it would be helpful for devs to select difficult bugs to work on during this period, so taking longer, as that should reduce the amount of book-keeping and catching-up. > Other alternatives would be to enable and use Savannah's normal bug > tracker, but I don't think that's going to be much of a help. No it wouldn't, only in extremis. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
