This is a very simple matter. https://github.com/roundcube/roundcubemail/pull/109
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 <[email protected]>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 <[email protected]> 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 >> [email protected] >> http://lists.roundcube.net/mailman/listinfo/dev >> > > > _______________________________________________ > Roundcube Development discussion mailing list > [email protected] > http://lists.roundcube.net/mailman/listinfo/dev >
_______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
