Suffocating development environment

[Andy Gumbrecht <ag...@tomitribe.com>]

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

Re: Suffocating development environment

[Romain Manni-Bucau <rm...@gmail.com>]

2017-06-28 13:19 GMT+02:00 Jonathan Gallimore <jo...@gmail.com>
:

> On Wed, Jun 28, 2017 at 11:35 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> wrote:
>
> > 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallimore@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 <
> > agumbrecht@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
> > > >
> > >
> >
>

Re: Suffocating development environment

[Jonathan Gallimore <jo...@gmail.com>]

On Wed, Jun 28, 2017 at 11:35 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <
> jonathan.gallimore@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"?

* 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.

* 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.

* 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?


>
>
> >
> > 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 <
> agumbrecht@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
> > >
> >
>

Re: Suffocating development environment

[Romain Manni-Bucau <rm...@gmail.com>]

2017-06-28 19:46 GMT+02:00 exabrial12 <ex...@gmail.com>:

> As one of the people that had a commit reverted, then history hard pushed,
> I
> think it should be a policy that NO git push --hard should ever occur.
> There
> was/is absolutely no justification for such childish behavior.
>

To be more accurate it was on svn and it was a merge so history was not
lost and revert was visible and not hidden.


>
> +1 for Andy speaking up in a polite manner and
> +1 for JG's examples and
> +1 for a keeping the old (non-angular) website around until a new one is
> actually ready and a vote can be called
>
>
Agree..there was one and we agreed to promote the experimental ng website
as the main site. We also kept the old one to not do a big bang (we only
lost the home page link which is using .old IIRC).

Side detail note again to be accurate: this is not an angular website.


>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/Suffocating-development-environment-tp4681969p4681985.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Suffocating development environment

[exabrial12 <ex...@gmail.com>]

As one of the people that had a commit reverted, then history hard pushed, I
think it should be a policy that NO git push --hard should ever occur. There
was/is absolutely no justification for such childish behavior.

+1 for Andy speaking up in a polite manner and
+1 for JG's examples and
+1 for a keeping the old (non-angular) website around until a new one is
actually ready and a vote can be called





--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/Suffocating-development-environment-tp4681969p4681985.html
Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: Suffocating development environment

[Jonathan Gallimore <jo...@gmail.com>]

On Wed, Jun 28, 2017 at 1:17 PM, Andy Gumbrecht <ag...@tomitribe.com>
wrote:

> The subject of this thread is intended to cover the multiple incidents of
> the past and address the increasing number of current and future concerns
> coming from multiple contributors, that will remain anonymous for obvious
> reasons. I am just being the voice with broad shoulders here.
>

I understand. I think you're trying to avoid a "witch hunt" which is good.
However, I think it is reasonable to "call out" specific actions politely,
and suggest some alternatives, so we all learn and can progress as a team.
We're all grown ups, and I'm sure we can have positive discussions and all
be stronger as a result. The problem with anonymity and broadly shouldering
the complaints of a number contributions generically, is it makes it hard
to know what you're specifically referring to, and therefore makes it
harder for people to learn what's an issue and what needs to improve. I am
by no means perfect (ask anyone, I'm sure they'll confirm that...), so if I
do something wrong, or could do better, I'd prefer to know about it, and
I'd prefer to know the specifics so I can grow, learn and help others. I
prefer it if the feedback is polite, and filled with suggestions on "the
right way(s)", of course.



>
> In this instance there were basically two simple human errors that
> should/would have been resolved in an orderly manner. They only serve as
> the example of how the current climate is, and why we should consider
> changing it for the benefit of the community. The thread topic should still
> be the focus.
>
> 1. The project was checked in missing the target svn ignore and it was
> never subsequently fixed, so the add pulled in target. This was only
> noticed during a commit in action. On attempting to rectify this simple
> mistake less than one minute later someone had already took it upon
> themselves to trash all commits rather than allow the problem to be
> resolved in an orderly fashion either through the ticket in progress or
> email - this came after the effect, i.e too late. Obviously this action led
> to multiple conflicts. Making it virtually impossible to recover.
>
> 2. The deployment to staging has often been used to provide access for
> review purposes in the past, but as Romain rightly points out there are
> risks involved in doing that, and a better way is to use the personal http
> spaces at Apache. The risks were still trivial and could be reverted in a
> matter of minutes if the staging were to be inadvertently published, but
> still agree that the personal space is the right place. That still does not
> warrant trashing someone else's work, ever. The problem should have been
> addressed appropriately. Acting in any other way is always going to inflame
> a situation, every time, without fail. Who likes having their evenings work
> deleted? Having it corrected is generally welcome I would guess.
>

A quick discussion of rollback / fail-forward on the dev list would have
resolved all of that easily, in my opinion. Side note, the use of personal
http space at Apache seems like a great way to review patches. The
documentation should include a reference to that.


>
> Both actions and the ensuing assertion in comments that the effort was only
> made in determent to the project, or only for the benefit of a third party
> company, is derogatory and inflammatory. Especially from whence it came and
> the potential conflict of interests involved already. This will again
> always result in a defensive response when it is simply not true. It will
> never result in a submissive response.
>
> Either way, the introduction of a 2 or 3 plus one workflow will completely
> mitigate any future issues like this. No one makes a commit with the
> intention of breaking something. Commits are made every day across the
> world that *do* break something. Everyone needs to understand that, and
> respond appropriately. Especially on an global  OSS project where people
> are dedicating their free time. TomEE is *not* a nuclear bomb that cannot
> be touched for fear of it exploding between stable releases. Version
> control is our saving grace. Community contributors need breathing space to
> grow into the project. Everyone makes mistakes. Mistakes should not be a
> means used to alienate new contributions, only as a tool to guide real
> people with real feelings in the right direction.
>
> To finish off. If work by contributors spans several days, or even weeks,
> then so be it. TomEE is not a full time project for many contributors. Most
> here have a life outside of the box and can only dedicate a limited amount
> of time. This means that it is simply not feasible to expect feature
> complete patches or commits. Incremental work must even be encouraged, as
> every step counts. The impatient must learn to become patient, and not
> trash incremental contributions.
>

I agree. I think that "Everybody should get to play", and we as committers
and PMC members should encourage that in order to bring new contributors
into the project, and steer them in the right direction. Things will break
from time-to-time, which means we need to be diligent about checking builds
and careful when creating releases, but it shouldn't discourage people from
having a go.

As I've already stated, I'm in favour of more discussion and review on dev@,
even for what may appear to be trivial changes.

Jon


>
> Andy.
>
> On 28 June 2017 at 12:35, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallimore@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-
> > r1800091-in-tomee-site-trunk-content-content-admin-content-
> > admin-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.
> >
> >
> > >
> > > 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.
> >
> >
> > >
> > > 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.
> >
> > 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.
> >
> >
> > >
> > > 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 <
> > agumbrecht@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
> > > >
> > >
> >
>
>
>
> --
>   Andy Gumbrecht
>   https://twitter.com/AndyGeeDe
>   http://www.tomitribe.com
>

Re: Suffocating development environment

[Romain Manni-Bucau <rm...@gmail.com>]

2017-06-28 14:17 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:

> The subject of this thread is intended to cover the multiple incidents of
> the past and address the increasing number of current and future concerns
> coming from multiple contributors, that will remain anonymous for obvious
> reasons. I am just being the voice with broad shoulders here.
>
> In this instance there were basically two simple human errors that
> should/would have been resolved in an orderly manner. They only serve as
> the example of how the current climate is, and why we should consider
> changing it for the benefit of the community. The thread topic should still
> be the focus.
>
> 1. The project was checked in missing the target svn ignore and it was
> never subsequently fixed, so the add pulled in target. This was only
> noticed during a commit in action. On attempting to rectify this simple
> mistake less than one minute later someone had already took it upon
> themselves to trash all commits rather than allow the problem to be
> resolved in an orderly fashion either through the ticket in progress or
> email - this came after the effect, i.e too late. Obviously this action led
> to multiple conflicts. Making it virtually impossible to recover.
>
> 2. The deployment to staging has often been used to provide access for
> review purposes in the past, but as Romain rightly points out there are
> risks involved in doing that, and a better way is to use the personal http
> spaces at Apache. The risks were still trivial and could be reverted in a
> matter of minutes if the staging were to be inadvertently published, but
> still agree that the personal space is the right place. That still does not
> warrant trashing someone else's work, ever. The problem should have been
> addressed appropriately. Acting in any other way is always going to inflame
> a situation, every time, without fail. Who likes having their evenings work
> deleted? Having it corrected is generally welcome I would guess.
>
> Both actions and the ensuing assertion in comments that the effort was only
> made in determent to the project, or only for the benefit of a third party
> company, is derogatory and inflammatory. Especially from whence it came and
> the potential conflict of interests involved already. This will again
> always result in a defensive response when it is simply not true. It will
> never result in a submissive response.
>
> Either way, the introduction of a 2 or 3 plus one workflow will completely
> mitigate any future issues like this. No one makes a commit with the
> intention of breaking something. Commits are made every day across the
> world that *do* break something. Everyone needs to understand that, and
> respond appropriately. Especially on an global  OSS project where people
> are dedicating their free time. TomEE is *not* a nuclear bomb that cannot
> be touched for fear of it exploding between stable releases. Version
> control is our saving grace. Community contributors need breathing space to
> grow into the project. Everyone makes mistakes. Mistakes should not be a
> means used to alienate new contributions, only as a tool to guide real
> people with real feelings in the right direction.
>
> To finish off. If work by contributors spans several days, or even weeks,
> then so be it. TomEE is not a full time project for many contributors. Most
> here have a life outside of the box and can only dedicate a limited amount
> of time. This means that it is simply not feasible to expect feature
> complete patches or commits. Incremental work must even be encouraged, as
> every step counts. The impatient must learn to become patient, and not
> trash incremental contributions.
>

This is true and what we agreed on for master sources but think we should
put the limit in term of direct end user impact. The website being directly
exposed it is easy to break them for 10H or more and a quick revert, even
if technically true, is not guaranteed at all. This is also why pubsub
plugin is not automatically wired to the generator. If we agree to use the
personal html area we solve that part - and probably need to create a
committer page on the website btw.

About target I guess Mark is our expert and can fix it very quick?


>
> Andy.
>
> On 28 June 2017 at 12:35, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallimore@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-
> > r1800091-in-tomee-site-trunk-content-content-admin-content-
> > admin-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.
> >
> >
> > >
> > > 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.
> >
> >
> > >
> > > 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.
> >
> > 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.
> >
> >
> > >
> > > 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 <
> > agumbrecht@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
> > > >
> > >
> >
>
>
>
> --
>   Andy Gumbrecht
>   https://twitter.com/AndyGeeDe
>   http://www.tomitribe.com
>

Re: Suffocating development environment

[Andy Gumbrecht <ag...@tomitribe.com>]

The subject of this thread is intended to cover the multiple incidents of
the past and address the increasing number of current and future concerns
coming from multiple contributors, that will remain anonymous for obvious
reasons. I am just being the voice with broad shoulders here.

In this instance there were basically two simple human errors that
should/would have been resolved in an orderly manner. They only serve as
the example of how the current climate is, and why we should consider
changing it for the benefit of the community. The thread topic should still
be the focus.

1. The project was checked in missing the target svn ignore and it was
never subsequently fixed, so the add pulled in target. This was only
noticed during a commit in action. On attempting to rectify this simple
mistake less than one minute later someone had already took it upon
themselves to trash all commits rather than allow the problem to be
resolved in an orderly fashion either through the ticket in progress or
email - this came after the effect, i.e too late. Obviously this action led
to multiple conflicts. Making it virtually impossible to recover.

2. The deployment to staging has often been used to provide access for
review purposes in the past, but as Romain rightly points out there are
risks involved in doing that, and a better way is to use the personal http
spaces at Apache. The risks were still trivial and could be reverted in a
matter of minutes if the staging were to be inadvertently published, but
still agree that the personal space is the right place. That still does not
warrant trashing someone else's work, ever. The problem should have been
addressed appropriately. Acting in any other way is always going to inflame
a situation, every time, without fail. Who likes having their evenings work
deleted? Having it corrected is generally welcome I would guess.

Both actions and the ensuing assertion in comments that the effort was only
made in determent to the project, or only for the benefit of a third party
company, is derogatory and inflammatory. Especially from whence it came and
the potential conflict of interests involved already. This will again
always result in a defensive response when it is simply not true. It will
never result in a submissive response.

Either way, the introduction of a 2 or 3 plus one workflow will completely
mitigate any future issues like this. No one makes a commit with the
intention of breaking something. Commits are made every day across the
world that *do* break something. Everyone needs to understand that, and
respond appropriately. Especially on an global  OSS project where people
are dedicating their free time. TomEE is *not* a nuclear bomb that cannot
be touched for fear of it exploding between stable releases. Version
control is our saving grace. Community contributors need breathing space to
grow into the project. Everyone makes mistakes. Mistakes should not be a
means used to alienate new contributions, only as a tool to guide real
people with real feelings in the right direction.

To finish off. If work by contributors spans several days, or even weeks,
then so be it. TomEE is not a full time project for many contributors. Most
here have a life outside of the box and can only dedicate a limited amount
of time. This means that it is simply not feasible to expect feature
complete patches or commits. Incremental work must even be encouraged, as
every step counts. The impatient must learn to become patient, and not
trash incremental contributions.

Andy.

On 28 June 2017 at 12:35, Romain Manni-Bucau <rm...@gmail.com> wrote:

> 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <
> jonathan.gallimore@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-
> r1800091-in-tomee-site-trunk-content-content-admin-content-
> admin-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.
>
>
> >
> > 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.
>
>
> >
> > 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.
>
> 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.
>
>
> >
> > 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 <
> agumbrecht@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
> > >
> >
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: Suffocating development environment

[Romain Manni-Bucau <rm...@gmail.com>]

2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <jo...@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-r1800091-in-tomee-site-trunk-content-content-admin-content-admin-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.


>
> 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.


>
> 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.

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.


>
> 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 <ag...@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
> >
>

Re: Suffocating development environment

[Jonathan Gallimore <jo...@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?

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.

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.

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.

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 <ag...@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
>

Re: Suffocating development environment

[Gurkan Erdogdu <gu...@yahoo.com.INVALID>]

Hi all
+1

From my observation in this list and some couple of ASF projects, you are absolutely right.  ASF projects long term success is heavily related with the healthy project community and their consensus (https://www.apache.org/foundation/how-it-works.html ). Projects must not be controlled and developed by anybody or any commercial organization. For example, look at the Apache Geronimo current state which was controlled and mostly developed by the commercial organization but now tin the stage of going to attic.
so more Apache way please (http://theapacheway.com/)

Regards.
Gurkan
 

    On Wednesday, June 28, 2017 3:14 AM, Andy Gumbrecht <ag...@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


   

Re: Suffocating development environment

[Romain Manni-Bucau <rm...@gmail.com>]

2017-06-28 2:14 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:

> 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.
>

We need to be more carefulness with that process because it doesn't work
Andy. We don't have a staging repo so it means if you push to staging and
somebody else push a change intended to the prod site (let say David fixes
a typo or adds an awesome doc on ejbd client for instance) then the staged
changes which are not yet desired would go live.

I don't know if we can get a staging repo linked to the staging site and
but it can be a way to enable what you desired yesterday.

Side note: the evolution of th website makes it trivial to run it locally
for any java/maven user so the staging is less useful IMHO which mitigates
this issue (whereas before the perl/python/bash env was a pain to run with
the right versions etc).

Last point which is nice not applying just to go in staging is to preserve
some history in our SCM otherwise we at least need to tak through the
commit message the commit as ignorable.

Side note: also please make sure to not commit target/ which is a temporary
folder, ensure it is in your svn ignore or we can add it remotely if needed.


>
> 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.
>

To make it clear the "other" was me.

However contrarly to what you think it was not a random and happy action.
The risk to trash the prod website was too high and the discussion about
the patch was in progress (days ago on the list and probably concurrently
on the jira).


>
> 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.
>


Well I'm not sure what you are thinking about but each time I did I sent a
mail or made the commit message obvious about why the change was done.
If you silently disagree you agree....



>
> 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.
>

Once again this is not what happens Andy. Most of the time it imples fixes
or preventing regressions like when some committer upgrades dependencies
versions and breaks TCK...


>
> 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.
>

I don't think it is related. Main issue is the lack of action when the
build breaks. We maybe don't have the same time notion here but days (to
not say more) without any try to fix the build looks not acceptable to me.


>
> 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.
>

We already discussed it and say it was not possible today due to the people
resources and that the gain would be too poor compared to the investment.
What would have changed?


>
> Looking forward to some candid responses.
>
> Best regards,
>
> Andy.
>
>
> --
>   Andy Gumbrecht
>   https://twitter.com/AndyGeeDe
>   http://www.tomitribe.com
>