2017-06-28 2:14 GMT+02:00 Andy Gumbrecht <[email protected]>: > 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 >
