This is where the work was done and this is my primary record of what happened. There are a lot of comments in there, discussions about how to do the cleanup and a lot of commits:

https://github.com/roundcube/roundcubemail/pull/109/commits

The core of the PR are only about 12 commits, plus 45 further commits to adjust to additional requests by the lead developers (on this list and on the PR discussion). I have spent my time negotiating those changes and to me, this record of the process is an important part of my work.

THIS is what I want to have on record (and yes, on the main repo) if we are to move forward. I want this PR to become merged, not any other in its stead. While it might be an uncomfortable or slightly chaotic record, it is the honest record of what happened and if my work is to be accepted, I want it accepted in the way it came about. If it is more important that it should be neat and tidy than honest then I disagree and take my work elsewhere. I don't want my work whitewashed and I'm getting a weird feeling that maybe that record in itself is a problem.

We can discuss finer points - Sure, some commit messages could be more precise (and I have offered to change the messages), but as you see from the discussion, mostly they were meant as replies to requests. I have tried making most of the commits descriptive yet with multiple tiny requests spread over days, you sometimes run out of steam on that. Anyways, that doesn't matter as it can be changed. So far, this hasn't even been acknowledged. Heck, you could probably even persuade me to git rebase a couple of those tiny commits away.

What I don't need is to be told that this is some actual technical challenge to have a couple dozen more commits on record, because that's simply bullshit. As I've said before: you're developers, stop pretending your commit history is some precious flower that cannot possibly be tainted. It's pure fantasy that there is any problem here and I wish everybody would stop making up more and more reasons that are just as ludicrous. You know what actually happens if somebody stumbles over this? It takes them a couple of seconds until they see "oh, it's a bunch of cleanup", then they move on. End of story.

Nor do I need to be told how this is a bad example to other developers because the work was chaotic or because you see yourself on some slippery slope where suddenly people no longer write proper commit messages. Bullshit again, because this is a question of whether you can keep the boat steady with a little turbulence. Not my problem, YOUR problem, but you want to make it mine.

I also don't need to be told how this comes across as unprofessional or how it would be so terrible to defend having a tiny bit of unprofessionalism on your record.


This is a very simple matter. I have offered my work and have now made a request that you accept some imperfections in the process for my sake. The response was that you like my work, but would rather not return a small favour. Instead of bearing a little discomfort yourself and maybe having to stand for a little bit of chaos publicly, you would rather have me make further concessions. I have offered concessions that I /could/ make, but nope, you would rather have me make the concessions that you want.

How you imagine that that is a premise for a working relationship going forward is beyond me.


I don't need to be here and I don't need to work on this. I have put a lot of work into this PR and six more PRs that were lined up, partially involving more work than this one.

But I would rather walk away from it than have my work distorted.

It would be a shame and a waste, but it's simply not my decision.


On Wed, Sep 18, 2013 at 7:50 PM, stephane martin <stef.martin@gmail.com> wrote:
Painful ? It's actually quite refreshing after a hard work day. Enjoyable.

Regards,
Stephane


PS : I'd be very interesting to talk about general accessibility/ergonomics too.


On Wed, Sep 18, 2013 at 7:14 PM, Paul Boddie <paul@boddie.org.uk> wrote:
On Wednesday 18. September 2013 15.23.56 David Deutsch wrote:
>
> Credibility? Eternalize? What? Look - I'm just a FOSS coder and I don't
> care how "professional" or whatever I come across. What I do care about is
> an /honest/ track record that can be seen in my github profile, amongst
> other things. I would like to help out in other projects as well,
> eventually, and I want to be able to offer an honest, cohesive picture of
> how past efforts went about. That's why I showed you what I did for RedBean
> - to give you a direct view into how it went down in another example. If I
> propose help to other projects, I don't think they would care much about
> how "professional" I am, but they would very much appreciate an honest
> picture of the process.

I'm mostly lurking on this list at the moment, having made an enquiry a few
months ago about something that I've not been able to prioritise (more below),
but this thread is too painful to read without commenting.

In principle I also am against the excessive rebase culture that a lot of Free
Software projects employ. The joke about this culture is that in its most
extreme form one wouldn't bother having more than a single commit in a
repository, and that commit would be accompanied by a message reading
"Perfection!", "All done!", "Project complete!" or "Nailed it!"

That you also see projects *making* version control software insisting on
rebasing or collapsing changesets, even though rebasing may be frowned upon
and collapsing changesets may involve advanced functionality, could be
considered akin to hypocrisy: people making tools to manage the information in
software development insisting that such information be thrown away. (Please
note that I'm not saying anything about Roundcube's commit or contributions
policy here.)

However, one should respect that projects do have commit policies for good
reasons. Some of these policies are infuriatingly strict: the Mercurial
project, for example, generally wants a single commit for enhancements, bug
fixes and new features (even though no-one in their right mind would do the
work in a single commit "for real"), and the commit message must adhere to a
specific format; all of this is on top of other policies one may or may not
like (line lengths, discouragement of comments, obligatory tests,
discouragement of new tests, obligatory documentation, and so on). It can take
several iterations to get something that the core developers will accept.

On the one hand, it can seem like people are just making life hard for casual
contributors. I am aware of one project controlled by a large corporation who
apparently makes contributing very much like a "ring of fire" experience
perhaps even more extreme than what I have described above. When people who
are paid to work on a project make more work for volunteers, one can
legitimately question their motives.

On the other hand, it is understandable that core developers do not wish to
readily take on more work that other people have thrown over the wall, giving
those core developers code to maintain forever while the contributors enjoy
the benefits of their work in the resulting product, with the contributed code
magically bug-fixed and updated for any and all of the architectural changes
and transformations that might come about.

As others have pointed out, your work will always be available in the form in
which you made it available if you continue to publish your
repositories/branches. Those who you wish to convince about the substance of
your work will still be able to see it and appreciate your efforts. But you
should also appreciate that those who have to maintain your contributions
should also get to choose how they can work with those contributions. Denying
those people any choice sends a signal that may be interpreted negatively by
others, regardless of whether words like "professional" are in their
vocabulary.

I think it is great to see your enthusiasm to improve Roundcube, and being
much more of a Python developer than someone who uses PHP, your work appears
to be beneficial to people like me. Please don't squander this opportunity to
see good work done by attaching a price to your contributions that may end up
with only you bearing the cost.

Paul

P.S. My original business on this list was to inquire about accessibility
support in Roundcube. If anyone has any thoughts on the topic (whether
Roundcube is perceived to be sufficient/deficient, whether work could be
done), I'd be happy to revive that thread.
_______________________________________________
Roundcube Development discussion mailing list
dev@lists.roundcube.net
http://lists.roundcube.net/mailman/listinfo/dev


_______________________________________________
Roundcube Development discussion mailing list
dev@lists.roundcube.net
http://lists.roundcube.net/mailman/listinfo/dev