On 11/28/19 12:47 AM, Siddhesh Poyarekar wrote: > On 28/11/19 10:55 am, Maciej W. Rozycki wrote: >> Well, I've been using it to track the state my own patches submitted (and >> during the period of my active MIPS GDB port maintenance also for other >> people's submissions). > > Can you please take a snapshot of your state? > >> Is it actually necessary to destroy all the recorded state (not only for >> patches, but also for e-mail accounts linked, which AFAIK cannot be >> restored once you've lost access to any) just for an engine upgrade? >> That would be an odd requirement and ISTR at least one of the patchworks >> I've had an account with to have been seamlessly upgraded at one point. > > Hmm, I will try to do an in-place upgrade without actually deleting > anything. I can't promise that it will go well because we'll be > upgrading from a very ancient version and I don't know right now if the > schema has changed incompatibly. > > I'll do a backup too FWIW.
When I looked at this the upgrade was *very* complicated, and carrying over the data from a version that is so old was going to be hard. >> Or do you have something else, i.e. not just an upgrade, in mind? > > To begin with, I intend to add hooks to close patchwork patches on merge > so that that aspect is automated. It was the one problem we had with > patchwork and with ChangeLogs gone in glibc, we're definitely a lot more > likely to get close to that goal. Agreed! For me as a reviewer, knowing what's up-to-date and ready for review, having a tool (like pwclient) to pull the patch and build a local branch from it, and then being able to use local diff tooling is really the key things to accelerate patch review for patches that don't require complex consensus. -- Cheers, Carlos.
