Re: [Kdiff3-user] Contributing and patch application

[Patrick M. <pa...@me...>]

Le 15/08/12 13:25, Joachim Eibl a écrit :
> Hi Patrick,
> 
>> Sorry if this is a little off-topic for the -user list but I could not find
>> a development channel, please redirect me if there is a better place for
>> this discussion.
> 
> No problem. For a private discussion you might write to my email as shown on 
> the homepage without the "__NO_SPAM__" part.

OK, I felt this kind of discussion about the project workflow should be public, just maybe not here.
 
> About your remarks: It is good of you to point them out because I didn't look 
> at it that way.
> 
> For the README file I applied the patches and noticed that there are more 
> things to fix and that's what I did, before I committed the changes.
> 
> E.g. the GPL exception was only necessary for Qt3 where for some operating 
> systems (Windows) no GPL version was available.
> 
>> I suppose the change itself is right, but I did not do it and it should not
>> be attributed to me. It is usually accepted to tweak submissions to fix
>> typos or whitespace damage but anything beyond this should at least be
>> discussed with the submitter. I am perfectly fine with you rejecting my
>> patch because of X and Y, talking about them and resubmitting, this is the
>> contribution game. That way all what gets in actually comes from me. This
>> is not a big deal with the "GPL extension" section I mentioned, but I am a
>> little unhappy with...
> 
> Completely understandable. I will be more careful about that in the future.

One thing I forgot to mention is beyond the philosophical stance, contributions to free software projects are more and more linked to resume and part of a developer public profile. Accuracy and visibility of submissions are rewarding for the contributor (though in the case of my patches this is completely irrelevant :-)).
 
>> 3- Why do you comment code instead of removing it?
> 
> Because I intended to use it, but then it was not that easy as expected. Yet 
> otherwise you are right of course. Probably I should just remove such 
> commented out code and rely on version control to fetch it back if needed.

This might also be subversion forcing the "commit is publishing" thing over you, with DVCS people would use private local branches for work in progress.

> I wasn't aware that others were looking so closely at my code ;-)

Kdiff3 looks completely broken on my OSX/macports QT4 setup right now, and for some reason I thought I could try fixing it myself. Before spending time on this project I wanted to know how "sane" and "alive" it was, and source control changelogs and diffs are a very good way to measure that. Here things did not looked good and I was curious if it was you lacking time or if it was deliberate, and if I would be wasting my time trying to contribute here. Which does not seem the case.

And yes, I have to file a bug report about my problem first.
 
>> Both way, it gives a feeling of uncertainty and confusion, it
>> seems you do not know where things are going.
> 
> The direction is much set by users. If some features or bugs don't make it, 
> then just due to lack of time on my side. There are so many things I'd like to 
> have in KDiff3 myself and don't get around to do them.
> 
>> I hope you do not find these comments too irritating, I really appreciate
>> kdiff3 and all the work you put in it, it is one few multiplatform,
>> efficient visual diff tools and is pretty important in the source
>> control/editing ecosystem. 
> Thanks.
> 
>> But contributing is a bit difficult and
>> unpleasant right now, and I prefer to talk about it rather than moving on.
> Yes. I've now activated the git repository on sourceforge will use this in 
> future instead of subversion. Perhaps this will help.
> If you have any concrete ideas, I'd like to know.

I have not looked at sourceforge git support but this is certainly a good step forward. It will make it easier for you to just import patches with commit logs etc.

Not sure I can suggest what to improve, but I can tell you what I look at before hacking on new projects:
- How easy it is to get the sources. I am not a subversion hater, far from it, but really for open source projects, DVCS are a godsend. Cloning is usually fast, you get everything and once it is there you do not have to deal with anything else than the clone (no browsing web based changelogs for instance). You can run all kind of tools on this, bisect, etc... So +1 for git even if I am not a git fan myself :-).
- How easy it is to build/test. Basically, how good is the README. Kdiff3 README is complete, but a little complicated. I would have expected to have one way to build it for all platforms (with minor tweaks on Windows as usual). Like cmake for everyone. Here you have a lengthy KDE section, then different instructions to build without KDE, for each platform. While historically all this comes from KDE, the project clearly moved beyond that, I use kdiff3 on Windows and OSX so. Maybe stress the KDE part a bit less. Anyway, it just *builds* and this is good.
- Tests. No tests (or I missed them in the README and sources). Not much to suggest on the "how" side but there are certainly parts (merging/diffing routines) which could benefit from some automated testing. And probably way to automate GUI runs.
- (Minor) Directory layout. The structure is not canonical for a subversion project, it is kdiff3/trunk/kdiff3 instead of just kdiff3/trunk. Not a big deal if you use subversion but complicates things if you use git or mercurial on top of subversion.

>> (Note I did not say a word about sourceforge :-)).
> Please give more info about what you mean by that. 

In 2012, sourceforge feels clunky and oldish. For instance, I was looking for a commit log browser and could not find it, only a subversion directory view with most recent commit attached to each file, which is completely useless. Notification emails are sent with no...@so... set both as sender and to, so you have to match the subject to write rules in email clients. The web based mailing list view is ackward to use. And so forth, a lot of small details telling its age.

The forking/pulling workflows implemented by github or bitbucket may be compelling too. They are not perfect either.

In the end you have to find a hosting solution matching the kind of workflow you want to implement for the project. Pasting diffs in webforms is a bit weird when you have git send-email, hg email or public forks, but experiences differ and your time is more precious than the one of your potential contributors at this point.

Thank you for all your answers, I am glad the discussion is actually constructive. Now I have to stop talking and file this bug report.
--
Patrick Mézard