[KPhotoAlbum] Improved Image Viewer? [PATCH]

Jesper K. Pedersen blackie at blackie.dk
Fri Dec 22 09:48:43 GMT 2006


On Thursday 21 December 2006 22:22, Shawn Willden wrote:
| Thanks for the response, Jesper, and thanks for taking it in the spirit in
| which it was intended.
|
| On Wednesday 20 December 2006 23:30, Jesper K. Pedersen wrote:
| > I'm afraid that the world unfortunately is not as black and white as
| > this. I do want to share. I do realize that the project could run much
| > faster were we several people to take care of it. Unfortunately, the 4-5
| > people I've asked to step up so far has all sayd no.
| >
| :-(
| :
| > Regarding packing, man have I asked for this forever. I don't have time,
| > nor interest, and esp not abilities to pack for a lot of different
| > systems. I've tried to pull of that I contacted the big players asking
| > them to pack, but even that takes a lot of time. So by all means, HELP!
|
| Okay, I'll try.  It shouldn't be too hard to build Debian packages, since I
| can use the kphotoalbum package in Debian as a starting point.
|
| > Regarding patches. The reason for my response is that I'm older than many
| > of the other projects maintainers, and thus more wise :-)))
| > Seriously, I always have to compare the time it takes to integrate a
| > patch with writting the code myself. Over the last few month, I've had
| > very little KPA time as you may know. Most of that time has been spent on
| > integrating patches. That includes everything from ensuring the correct
| > naming convention to the right way of doing it. I DO WANT MORE PEOPLE TO
| > CONTRIBUTE to the project, but by far I prefer people contributing a
| > longer time with many patches than just with one monster patch, and then
| > running of.
|
| Hmm.  I have some suggestions that may help.  They may be things you've
| considered and discarded -- perhaps for good reason -- but I'll offer them
| anyway.
|
| 1.  Perhaps it would help if you put together a brief (1-2 pages) style
| guide that covered most of your key requirements regarding structure,
| naming conventions, etc.  That way when you get a patch submission, you
| could point to the guide, and ask the submitter to please comply with those
| guidelines. That might reduce (though not eliminate) your patch integration
| effort.  If you're not sure what to put in the style guide, just build it
| bit by bit as you notice problems in patches.
Well I'm in general against these kind of rules for two reasons.
1) They will take time from my coding
2) more rules makes people less happy about helping out.

The things I complain about is stuff like people starting writting code like 
This_is_a_variable, while the rest of the code is thisIsAVariable.

etc.

If you want to try and write some guidelines from looking at my code, I'd be 
more than happy to comment on it.

| 2.  When you get patches that comply with the style guide, but still don't
| meet your expectations, I think it might be more effective if you push back
| on the submitter and make them fix the patch, even if it ends up delaying
| the patch integration, and even if it seems easier just to fix it yourself.
|  What you'll get out of this longer and more tedious process will not only
| be a good patch, but it will also be an educated contributor.  Of course,
| telling people to fix their code without making them angry at you isn't
| easy.
I try to do that already.

| 3.  Raising the quality of the required patches may reduce the flow of
| patches, so you also need to increase the number of people willing to
| contribute, and I think Lars' suggestion is a good way to do that.  If you
| could provide some documentation on the structure of KPA so that potential
| contributors could get into the code quickly and easily, more people would
| be willing to help out.
Well in a perfect world where I would have all the time, I would love to write 
such documents, but currently I have less than a few hours a week (Sunday 
morning when my gf still sleeps, and before I go back to my business 
economics studies), so that would take forever.

What I try to do is constantly add comments to code explaining that each part 
does. I also have spent rather a lot of time to put things into modules so 
that it is easier to find the right file.

| All three of these ideas are, of course, more work for you in the short
| term, but I've seen in other projects how they actually help a great deal
| in the longer term.
And I _do_ appreciate the suggestion, it is just an investment I can't afford 
right now.

And I've never let down a single request from anyone on finding their way 
around the code. When awake I'm always on #kphotoalbum, and people there will 
ack. that I'm quite responsive (see this time is from waiting on my compiler 
at work ahem)

| As I said, I'll explore creating Debian (and maybe even Ubuntu) packages of
| your snapshots.  Also, I'd be happy to help with structuring and critiquing
| a kphotoalbum architecture document, although you'd obviously have to do
| most of the work.
Please figure out who is the real  maintainer if there is such a guy, and 
ensure that the result of your work goes to him.

Cheers
jesper.

-- 
Having trouble finding a given image in your collection containing
thousands of images?

http://www.kphotoalbum.org might be the answer.



More information about the Kphotoalbum mailing list