2017-06-28 13:19 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com> :
> On Wed, Jun 28, 2017 at 11:35 AM, Romain Manni-Bucau < > rmannibu...@gmail.com> > wrote: > > > 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore < > > jonathan.gallim...@gmail.com> > > : > > > > > Wow. > > > > > > Well, thanks for writing the email, and starting the discussion. From > > where > > > I'm sitting, it looks like there are a few issues. I'll work in > > reverse-ish > > > order (in terms of your post). > > > > > > -- Reverting commits. > > > > > > I've seen the reverts - I also note that other than on a JIRA ticket, > > there > > > was zero conversation on the dev@ list. This isn't the first time that > > > this > > > has happened, and in my opinion, is fundamentally wrong. If there is a > > > genuine need to revert something, you need to post to the dev@ list, > > call > > > out the commit, and say why it needs reverting. The person proposing > the > > > revert should be prepared to have a should we "roll-back or > fail-forward" > > > conversation in the community, and not simply take it upon themselves > to > > > make that choice. Folks might be wondering why we need to do this (I > > think > > > there is a perception that their mail might not be read, so why bother > > > posting) - reasons are simple: > > > > > > * Encourage discussion and contribution - discuss the specific issues. > > What > > > stopped working? Does the committer know what they broke, or what the > > > reason for proposing a roll-back is > > > * Co-ordinate - if something breaks in a commit, deciding who's going > to > > > help fix what might be better than rolling back > > > * Educate - is there a process where something in staging becomes live > > > automatically? Is that what we tried to avoid this time? Is there a > > better > > > way to build the site and stage it for peer review? > > > > > > > FYI > > http://tomee-openejb.979440.n4.nabble.com/Fwd-svn-commit-r18 > > 00091-in-tomee-site-trunk-content-content-admin-content-admi > > n-cluster-content-admi-td4681967.html > > was intented to host that discussion (and not pollute jira) > > > > Note that it is what happent most of the time, not sure why these dev > mails > > are missed. > > > > That's now been pointed out to me twice since I posted this. Actually saw > and read that post before posting. If you think that constitutes a clear > discussion, and justifies your actions - sorry, but I'm afraid I could not > disagree more: > > * You replied to commit. Yes that hits the dev@ list, but was the shortest > possible thing you could have done, and in reality had almost no > visibility. However, you didn't change the title, so at a glance, its hard > to distinguish from the commit messages themselves. To answer your question > - this is most probably why they are missed. Do you really think "Fwd: svn > commit: r1800091 - in /tomee/site/trunk: content/ content/admin/ > content/admin/cluster/ content/admin/configuration/ content/advanced/ > content/advanced/applicationcomposer/ content/advanced/client/ > content/advanced/jms/ content/advanced/shading/ co..." is a good subject? > How about "Please don't push these website changes to production". Or > "[DISCUSS] [REVERT] breaking website change"? > Fair enough, noted! > > * Your single line message "Please don't publish this, it breaks existing > links which is pby sthg we don't want to do now. Pinged Ivan about it", > tells us very little. You make no mention that you intend to revert it, and > very minimal information on what the issue is. How are we supposed to > discuss it if we don't know what the issue is? Side note - I don't know how > well people with less English knowledge get on with the abbreviation of > "probably something". This is just a suggestion, but I'd avoid the > abbreviation of those words on your already very short message. > Yep, at that time there was an implicit assumption based on the dev thread which was the patch would be discussed before being applied. Guess I was in this mind when forwarded the mail/ > > * You "pinged" Ivan - privately, I assume. I have no visibility of that. > Why not just post it on dev@ and have the discussion in the open. Maybe > we'll all learn and improve and collaborate as a result. Maybe we'll appear > as a more welcoming community. The private conversation is exactly what we > should avoid. > Fair too, just thought it was directed comments so didnt need to be shared and bother others with it. > > * If I have read commit emails correctly, your revert (which actually shows > _before_ your post to dev@ in my mailbox, by the way), your revert commit > happened within 60 seconds of your post. Not exactly a lot of time to > enable a conversation, is it? > This was not the intent, intent was to show that the operation was intended and open the discussion if needed (= if reading it you understand why then no need to discuss and we just need to polish the patch on the thread + jira). > > > > > > > > > > > > All of the above potential (and that's just off the top of my head, I'm > > > sure there is more) was lost by the 'silent revert'. The view the > > committer > > > / contributor has becomes "my stuff was rejected without comment and > > > without discussion, why should I bother?" and the damage to community > > > starts / continues. In my opinion, simply reverting commits without > > > appropriate discussion on dev@ needs to stop, right now. We need to > > > nurture > > > contributions, not simply reject them. > > > > > > I saw one point about breaking the build, and the build not being fixed > > > quickly enough. Again, I think that needs to be called out and > discussed > > > how to fix (rollback or fail-forward), as opposed to commits being > > rejected > > > or reverted without discussion. It also needs to be understood and > > accepted > > > that we will need to have that sort of conversation each time it > happens. > > > Even if a change breaks something, I don't think anyone should have > > "carte > > > blanche" to revert commits without discussion on dev@. > > > > > > -- Making changes. > > > > > > So let's talk about the elephant that isn't in the room. Simply put, > > there > > > isn't enough discussion on dev@ and there is virtually no peer review > at > > > all. Andy, I wasn't aware that you'd be pushing stuff to staging, and > so > > > those commits, from where I was sitting, came out of the blue. I will > > note > > > that there was some discussion around TomEE documentation, which is > > great, > > > but the commits I saw were so big that I couldn't get a diff of them. I > > > will go through and review, but that is going to take some time. At the > > > moment, I don't know what the changes were so I can't really comment on > > the > > > specifics. There was no invitation to review or discuss. There was no > > > discussion around the process of building a local copy of the website > and > > > maybe staging it somewhere else to facilitate that review. The > > > documentation on contributing to the website and review changes is, I > > > suspect, somewhat lacking. > > > > > > > raw doc to do an update/submit a patch is > > http://svn.apache.org/repos/asf/tomee/site/trunk/generators/ > > site-tomee-ng/README.adoc > > > > then it is just a matter of synching target/site-tomee-ng* with content/ > of > > the site (pubsub). We can surely setup pubsub mvn plugin to make it > > smoother if needed. > > > > Here's what I found on tomee.apache.org: http://tomee.apache.org/ > community/ > index.html. The information in that .adoc would be useful on an actual > page > on the website. > > > > > > > > > > > > > You mention that you were mentoring a contributor - you don't mention > > who, > > > but I'm assuming its Ivan Junckes for a bunch of reasons, but mostly > > > because of his conversations on the TomEE documentation thread. Please > > > correct me if I'm wrong. Anyway, whoever it is, we'd love to see more > > > contributions from you. I understand that this negative experience > might > > > leave a bad taste, but it would be great if you bear with us and please > > > carry on - I am very hopeful that we can improve, and in turn, enable > you > > > to contribute more and help the community grow. We would appreciate > your > > > feedback to help us do so. > > > > > > While I saw some patches attached to the JIRA, I think a better process > > > would have been to have contributor talk about their patch on dev@, > how > > to > > > build it and review, and what what the changes are. It seems like > we're > > > relying on JIRA heavily, almost as a replacement for this mailing list > - > > > that should stop too. Discussions should happen on dev@ and give > people > > > the > > > chance to respond. One side note on that - I really don't want to see a > > lot > > > of "lazy consensus", where "I didn't get a reply in 72 hours and 1 > second > > > so clearly everyone agrees" - if you get no replies - follow up. > Provide > > > more information. Ask what people need to make replying easier. Do they > > > need a test to run, or a simple command to execute? More description? A > > > report showing library changes? A copy of the website running somewhere > > to > > > review? The easier it is to reply, the quicker the responses will be. > > Also > > > accept that people may just *need more time*. Like many, I have a busy > > > full-time job, and invariably I sometimes have to work a bit extra at > > that. > > > I also have two demanding kids to entertain, feed and put to bed. > Things > > > seemed so much simpler back in 2007, as I had more time. I'll do > > anything I > > > can, but a 72 hour deadline is sometimes just not long enough. > > > > > > As an example of discussing before committing, I proposed a patch here: > > > http://tomee-openejb.979440.n4.nabble.com/MDB-JMX-Control- > td4681962.html > > - > > > I have had a couple of items of feedback (thank you Romain and > > Jonathan!). > > > I now need to follow up on that discussion, update my patch and push > the > > > discussion on again, whilst also trying to obtain some more views for > the > > > discussion. I have another patch which is a little more complex which > > I'll > > > be proposing today as well. Please note that I am not saying I am > > perfect, > > > and I am not saying those conversations are perfect either, but > hopefully > > > they provide something to think about and improve upon. > > > > > > > It is best done this way but I think - correct me if wrong - it is fine > to > > push something you think right (speaking of SNAPSHOT, not the website for > > the already mentionned reasons) and then got a ping on the list saying > "hey > > man you broke something, if you dont fix it now i'll revert it and we'll > > see how to add it back". We all do it on our free time so I tend to > > encourage action and hard fixes when needed than list "idling" which > often > > happens. > > > > > > > > > > So, in summary (TL;DR if you like): > > > > > > * Propose rollbacks on the dev@ with reasons. If you had to -1 > > something, > > > you need to give a visible reason - same should apply here > > > * More discussion on dev@ before commiting > > > * Encourage contributors to present their proposed changes and discuss > > > their diffs on dev@ > > > * Don't rely on JIRA comments for discussions - if it didn't happen on > > the > > > mailing, it didn't happen. > > > > > > > Except the second point it sounds good - but thinking about it this 2nd > > point can need some classification like "bug fix", "regression fix", "new > > feature", "spec impl" or anything enabling to judge if a discussion is > > needed or not. > > > > You mean "* More discussion on dev@ before commiting" comment? Whether > it'll actually happen or not, well, we'll see. In terms of my opinion, I'm > not going to budge on it. Even for a simple change like a dependency update > or a little bugfix, you can throw out a little heads-up on dev@, and check > no one objects. Its not hard and doesn't need to take a lot of time. > > > > > > > Also think the first point need its corollar: don't apply a diff which is > > under discussion on the list until it got ack by this discussion. > > > > Not applying the diff without review is covered by my second point ("* More > discussion on dev@ before commiting"). I also stand by my first point. > Andy > committed something which you had an issue with. You went and wiped it out > with virtually zero discussion, and no replies. Sometimes people make > mistakes, and break stuff. If happens. Sometimes they omit to post on the > mailing list, whether that omission is intended or not. You had the > opportunity to be a "bigger man" and help promote the discussion and build > the community. You didn't take it, you instead chose to simply revert. > > Jon > > > > > > > > > > > > > I hope that my views above are seen as reasonable, balanced and helpful > > > (which is my intent, and how I hope it comes across). > > > > > > Andy, thanks for kicking off this conversation, I too, hope there will > be > > > some good, considered, responses on here. Also thank you for taking the > > > time to work on the documentation with another contributor (Ivan?) - > and > > > thank you to them too. > > > > > > Jon > > > > > > On Wed, Jun 28, 2017 at 1:14 AM, Andy Gumbrecht < > > agumbre...@tomitribe.com> > > > wrote: > > > > > > > I'm writing this on the public dev list as there seems to be inaction > > on > > > > the private list regarding the preservation and nurturing of > > > contributions > > > > to the TomEE project. I hope this serves as an entry into a public > > > > discussion on how to improve or resolve the situation. > > > > > > > > This evening (and late into the night) I was working in my free time > > > > together with another contributor in an effort to improve the > currently > > > > very poor TomEE website. This work was offsite, and being pushed to > > > staging > > > > for peer review. > > > > > > > > It became apparent that another committer deemed it in some way > > > acceptable > > > > to trash this effort 'during' this work without any collaboration > > simply > > > > because they disagree with some of the changes, even when those > changes > > > had > > > > not been finalised. The existence and state of the JIRA ticket was > > > > completely disregarded by this committer. > > > > > > > > This is not the first time that a committer has performed such > arrogant > > > and > > > > destructive actions on other peoples contributions to the project. > Such > > > > actions are always extremely disrespectful at a personal level. This > is > > > of > > > > course reflected by the state of the community that currently feels > > void > > > of > > > > any participation specifically due to this kind of mobbing. It has > > become > > > > virtually impossible for contributors to perform any work on the > > project > > > > without almost instant negative, rather than positive or nurturing, > > input > > > > at every level (even documentation). I know of several potential > > > > contributors who have avoided the project due to this currently very > > > > predictable attitude. It has in fact almost become a joke within > other > > > > communities. > > > > > > > > Maybe speaking for others, it is no secret that some committers do > not > > > get > > > > along with others due to these reasons. However, I do value the > immense > > > > contribution by every committer to the TomEE project and understand > > each > > > > individuals value and rights to and on the project. This does not > mean > > > that > > > > one individual is the owner of this project (we all are) and has the > > > right > > > > to overwrite or trash other peoples work in progress, no one should > > ever > > > > have that sole right. Well actually we all do, and this seems to be > the > > > > fundamental problem. > > > > > > > > We desperately need to instigate some measures to prevent the further > > > > demise of the TomEE community by individuals that seem intent on > > breaking > > > > it for reasons that go beyond me (well actually they don't, but > that's > > > > another story). I believe that there was a past discussion on > > > introducing a > > > > 2 or 3 plus one workflow into the the project, whereby all commits > must > > > > undergo a peer review. This may somewhat stifle rapid development, > but > > on > > > > the other hand it would ensure that commits are stable and not open > to > > > > trashing by others. > > > > > > > > Given that the current JIRA practice is now to commit before creating > > the > > > > actual issue (which has been encouraged by the overly aggressive > > > > environment), the peer review system would also return that process > > back > > > to > > > > a normal and acceptable state. Therefore I would like to suggest we > > begin > > > > taking the necessary steps for the introduction of this process. > > > > > > > > Looking forward to some candid responses. > > > > > > > > Best regards, > > > > > > > > Andy. > > > > > > > > > > > > -- > > > > Andy Gumbrecht > > > > https://twitter.com/AndyGeeDe > > > > http://www.tomitribe.com > > > > > > > > > >
