Patch-review changes
David Nolden
zwabel at googlemail.com
Sun Feb 21 15:59:56 UTC 2010
Am Sonntag 21 Februar 2010 16:28:11 schrieb Andreas Pakulat:
> On 21.02.10 15:17:26, David Nolden wrote:
> > I've tried out the changes to the patch-review now. Unfortunately, Aleix,
> > it _stilll:_ doesn't work properly.
> >
> > I've written you an extensive (though short) list in my last email of how
> > the stuff is supposed to work. Unfortunately this still isn't the case.
> >
> > I find this very frustrating, because I've already had the patch-review
> > working perfectly once
>
> Certainly not, last two times I tried it it just crashed (thats been
> before christmas though)
>
> >, and now it seems like it's up to make to make it work
> > properly for a second time. I won't do this though, since you still
> > haven't explained to my why _exactly_ all these changes are really
> > required.
>
> As far as I understood they were needed to make git work, additionally
> we had a fork of libdiff2 which nobody maintained or tried to merge back
> with the maintained original library. Thats not an acceptable situation
> for a plugin we ship.
There were much easier ways to achieve that, by simply adapting the patch. Of
course, we can from now on start to merge the libdiff2 code once a month, but
as long as there is no problem with the code, that is completely wasted
effort. There were no problems in our version of libdiff2.
> > All in all, I've alrady wasted far too much time with this. In half of
> > the time I wasted testing the patch-review changes, I could have made the
> > old patch-review work with git patches, which was the original motivation
> > of this.
>
> But you didn't do it and Aleix stepped up and tried to make it work,
> even tried to fix this broken situation with an unmaintained
> library-fork.
See above, the fork worked perfectly.
> > I hope you don't mind too much if I revert to the old patch-review now,
> > and take another path to make it support git patches.
>
> I do mind, either make it work with a libdiff2 that has no or only
> minimal changes to "upstream" or leave the fixing to others and revert
> it locally if you need to work with it.
You cannot fix something if you don't even know how it is supposed to work,
and that was the basic problem here. Anyway, end of discussion.
More information about the KDevelop-devel
mailing list