Re: Patch queue

[Vincent Legoll <vincent legoll gmail com>]

On Sat, Apr 11, 2009 at 3:46 PM, Stephen Kennedy <stevek gnome org> wrote:
>> I would like to know what to do with all the patches I sent for review,
>
> I think they're all good to go unless you've heard any explicit dissent.
> (i.e. the split filtertext message :))

OK, I'll commit the simple backslashectomy then.

>> I have other patches to send but some of them depend on the
>> previous batch. For example preliminary plugins for: prcs, arx,
>> svk & fossil, perforce & patch file. (for which I have a test setup)
>
> Excellent, though I'd like to see some testing before these go in
> as we're so close to a release. The one exception is I'd love to see
> patch support and volunteer myself for testing. I'm sure there are
> more people who'd be interested too.

The patch file support I have been working on is not finished, and I
don't think it will be for a near-term release. I don't want to rush on
that one as it asks for some not trivial modifications in vcview & vc
subdirectory.

If you want to try it, I'll rediff the patch posted in bug 572565, as it
should not apply cleanly now, and update that bug report.

Don't be afraid this one is high on my todo list, partly because I'm
really annoyed by kompare bugs, which make me want to ditch it
in favor of meld for patch viewing... ;-)

I think the other plugins could go in before a release, because there
should be no regression for something we didn't previously support.

OK, a bad interaction with multiple-VC could probably cause a
regression somewhere. So I'll let you decide, but if you want them,
I'll need to port them to current meld code base, as they are
dependent upon other modifications I still have not committed.

Maybe it'll be better if we release early without further new functionality,
only fix the last bugs we want in, and then go wild after that...

>> I have cleanups & factorizations in VC, filename-based VC plugins,
>> fixes for current VC plugins wrt diffing multiple files & launching diff
>> on the repo root, migration to subprocess everywhere (with
>> factorization of lots of code), diff only modified files, cleanups, the
>> VC unittest work...
>> Do you want to make a release before all of that happen ?
>
> Yes, I'd be wary of sweeping changes, especially as it has been so
> brittle in the past.

Perfect with me, do you need some specific help for the release ?

So I'll commit the batch of patches already sent for review, and wait
after the release for the next ones. OK with that ?

-- 
Vincent Legoll