Hi Chris, I'm aware that I'm not responding to your previous reply exactly but my reaponse is still on this overall thread so that's OK. This thread seems to have, rather drastically turned into a bit of a pissibg match on one hand and borderline argument on the other. Which is uncharacteristic and with which I feel extremely uncomfortable. That fact that you've somehow inferred that your take extreme offense to some of (what I though was modest, civil) correspondence is concern for me so I'm ceasing my participation in this thread. For reference, the PR I was referring to can be found below https://github.com/apache/climate/pull/195 My opinion is that th correspondence which went on here was very civil. IMHO a CTR workflow would have been the wrong decision in this case however I digress. @Kyo, My comments still stand as per my last comments, if you require assistance with any aspect of your committer rights or anything else as suggest by Mike on issue 195 then please come to the list. I take it as a failure on my part, as a member of this PMC to have let you down if this is what has happened. It is the first time that I've been in this situation so I am hoping we can remove the barriers and enable you to commit your contributions as you should have been able to do ages ago.
On Tuesday, May 12, 2015, Lewis John Mcgibbney <lewis.mcgibb...@gmail.com> wrote: > Hi Chris, > Please see replies inline > > On Tue, May 12, 2015 at 6:10 PM, <dev-digest-h...@climate.apache.org > <javascript:_e(%7B%7D,'cvml','dev-digest-h...@climate.apache.org');>> > wrote: > >> >> I’m honestly not sure what you are talking about, > > > Not even one wee bit ;) maybe some of my replies will bridge the gap > between you not being sure about what I am talking about Vs disagreeing > with what I am trying to say. > > >> and to be honest, >> waiting 72 hours before committing everything is not a project I’d >> ever want to be on. > > > Well lets for a minute consider the flip side (or another possible side) > of this coin. I would never want to be on a project where patches are > merged which clearly break > 50% of the tests in the entire codebase. It > seems to me, rather detrimental to the project codebase as well as other > community members who have confidence in a codebase for patches to be > committed and merged whcih essentially break everything! Additionally, this > goes against all of the good practice I've ever learned since stumbling > across TheASF some 6 years ago! I can't word this opinion any other way. > > >> Like I said - if I care about a review, or >> want something to be seen by someone, fine, I can choose to ask for >> it. > > > Absolutely correct. I agree. > > >> It shouldn’t be *imposed on me*. > > > It seems like imposed is a strong word given the sentiment of the thread > and the openness of Mike to open it up initially to how people want to do > things. I think what we are trying to determine here is whether people feel > like things are being imposed upon them. If that ends up being one of the > outcomes of this thread then we need to accept, address, change, implement > and move on. > I consider a grace period as a politeness as well as a duration which > people can gauge the contribution(s) and comment accordingly. That is all. > It is not so people can shoot it down. That would be detrimental indeed. > > >> BTW Apache projects and their >> conversation need to happen at the ASF and I’m seriously concerned >> that’s not happening here. There is too much reliance on Github >> for this project. >> > > I understand what you are saying here Chris. There is a lot of development > chat going on at Github. This is on an issue-by-issue bases AFAIK however, > therefore I am of the opinion that essentially this is no different from > the same conversation happening over on Jira and the same messages being > shadowed over onto dev@. The reason I say that is that (with my > experiences of mentoring Apache Usergrid) communities should not be > *forced* to use Jira over Github. The same messges are shadowed to Jira and > to the Mailing Lists. This is a nuance of the communication workflow. If > this is a major issue (we've been here before haven't we ;)) then it needs > to be dealt with. This argument has a lot of precedence at the foundation > and we can dig it up if need be. > What is your suggestion then Chris? That all correspondence is moved to > Jira? That it happens on the ML? That we find a balance between the three? > > >> >> Yes. Flat out. We don’t VOTE 72 hours on every line of code, or every >> patch, >> or waiting for a grace period to commit things. > > > There was no mention of VOTE'ing at all AFAIK. All commentary thus far has > referred to a 72 window for community commentary that was all. After this > 72 hours (not months) it is absolutely cool to commit away. BTW, it is also > cool to commit away before those 72 hours. There is no Bylaws established > by OCW to state anything any different. This combined with the pre-commit > build for the project has kept builds stable on OCW for as long as I can > remember. It seems to be doing a reasonable job at keeping the test suite > stable and passing successfully. I would have thought that this practice > would have been fine given the fact that comments typically come in before > 72 hours and I've seen a bunch of patches committed before 72 hours as well. > > >> Things that are big >> changes, >> controversial, sure, get feedback from others. > > > Yes. I agree. > > >> If I want to add a test. >> Update >> something that isn’t being used in the code base, or that doesn’t even >> have >> tests to show how it works one way or another? Someone should be able to >> press >> forward on that. Releases? 72 hours. New PMC/committers? 72 hours. A new >> JIRA ticket, >> etc.? Not sure we need that. >> > > I think there is an issue here though. It's not this type of thing that 72 > hours is in place for. It's proposed patches which break the build and test > suite and mean that others working off of master cannot keep up to date > with master. That is what the workflow guards against. Someone please > correct me if I am wrong. > > >> >> >> No it has to do with two people on this project (Joyce, Whitehall) >> seemingly >> to me suggesting things that Kyo continue to keep doing to his ticket >> before it should be committed - and vice versa - him in turn doing the >> same thing to their tickets and so forth. > > > No comment. > > >> And Kyo not even knowing that >> he has direct commit access to the Git repo at the ASF > > > That's a clear failure of the PMC and Kyo's introduction to the PMC in > communicating to Kyo that he has commit rights to the canonical source code > and that he can essentially commit whenever and whatever he likes. That > seriously needs to be addressed. > > >> , and honestly a >> guide >> that I was pointed to that says the primary source code base for the >> project >> is at Github (newsflash: it’s not - that’s where our *mirror* is). >> > > I've never seen it so no comment. I am aware that canonical source is at > Apache. > > >> >> How many other people are getting batch emails? > > > Here or at Apache? I honestly do not have the answer to either Chris. > > >> Also, batch emails are good >> for catching up later, but I see most of the activity on this project >> being >> automated emails from JIRA and Github. > > > Are these automated emails not happening as a result of development issues > being discussed on either Jira or Github? My thoughts are yes. > > >> Lewis as a member of the foundation >> I’m sure you’re privy to the recent strife and discussion related to this >> over >> the years > > > Absolutely I am. I've also however seen extremely successful > Apache-compliant Github workflows dramatically increasing development and > interest in codebases. Usergrid is an excellent example of that. We really > struggled over there for a number of months with an entire PPMC nearly > opting to leave the Incubator due to what they saw as ridiculous > constraints upon what Infra wanted them to do. My justification for getting > involved in this thread is because I felt I learned a lot from that > experience and I hope I can help out here! > > >> - a project’s sole source of activity and conversation related to >> development cannot be automated emails from bots. We should probably be >> discussing dev related stuff in emails. That’s still the lowest common >> denominator. >> > > I checked out the mailing list archives and almost every message is > generated automatically. So your point is utterly valid. I would ask if you > if you think disassociating all contextual development communication from > Jira or any other issue tracker is a wise thing to do? > > > >> >> What are community suggestions? > > > I'm looking forward to hearing them. > > >> I see PRs from Kyo getting many suggested >> revisions from Whitehall and Joyce - and then I see similarly some issues >> when they try and push code. I see Mike being the guy to integrate and >> push >> PRs after review (his own and other people’s). That’s scarily like a BDFL. >> > > I don't see it this way. I would be pretty convinced that Mike can speak > up here and state that he would wish others to commit their own patches. > > >> Yes I said it. Is Mike the merge master? > > > Not at all. If you check out my other thread I sent in reply to Kyo, there > are 29 Committers with write access to the codebase and 42 subscribers to > this list in all. That is a hellish impressive number of people to have on > the PMC. The truth though Chris is that is it were not for Mike then I > would have had nothing committed to the codebase! That is the reality of > the situation with most of the patches which have come to OCW. I > acknowledge and highly suggest (and expect) that this behavior will > certainly change after this thread. > > >> Has he thrown up a VETO on Kyo’s >> code? > > > I don't think so no. > > >> What about Whitehall? > > > I don't think so no. > > >> What about you? > > > No. > > >> That’s about the only thing >> that can stop him from committing to the code base directly. > > > Exactly. > > >> He is a PMC >> member and I’m sorry and not going to dance around the issue anymore - >> he’s >> not being treated like a PMC member. And I’m bringing it up and not >> sweeping >> it under the carpet. >> > > This is a foreign concept to me and I was not aware that Kyo was not being > treated as a PMC member. Unless I have missed this corresponence happening > on list then I was not aware of it. The list (as you've mentioned) is the > canonical location for project communication. I've seen nothing to suggest > that Kyo is not being treated as a PMC member. I hope my enthusiasm in > trying to reply to some of his concerns today emphasize that. I just hope > it is not too little too late. > > >> >> I don’t think it’s working well. In fact, I know it isn't. See referenced >> email from Kyo. > > > I replied. > > >> He’s finding it difficult to contribute. > > > Well we need to help with that. That is the only way forward. The mailing > list is open for this kind of communication. Frustrations are all too often > voiced here which is probably too late. I would like to call out Kyo > personally and state that if you read this, and you are having an issue > contributing to the OCW codebase over and above community comments then > please let us know. We can either sit down one-to-one, in company or else > the PMC can maybe even do a casual hangout and we can resole the committer > issues. > I would like to also point you to the following resources Kyo > http://apache.org/dev/contributors.html#providingfeedback > In particular it details how to submit patches and provides guidance for > what those patches should minimally do. I quote > " > > change the sourcefiles to incorporate your change or addition. Make sure > you also provide appropriate source code documentation (like javadoc for > java sources), and follow a project's coding conventions. > > check the software still compiles and runs correctly > > run any unit or regression tests the software may have > " > If there is any part of this or anything else which we can aid with then > please let us know on the list. > > > >> I’ll help spell >> that out for you here in plain English. *He is a PMC member on this >> project >> and finding it hard to contribute*. Can I make it more clear? >> > > I see stating the problem as a given. Resolving it is another kettle of > fish. We will get there though Chris :) > > >> >> I do. It’s too long. > > > Too long for what? Is development on OCW time sensitive? > > >> Please let me know the sacred vow that breaking >> a test on OCW causes. > > > Non at all. It is development code afterall and hey that is what source > code management systems are for right? Sh*t I am all for breaking project > builds I done it many times before or many projects. I am however also for > taking on board a Jenkins message which tells me I've broken a number of > tests. > > >> We have 0 users of the project. We are our own >> users. > > > This is not true Chris I am sorry. I was only talking to someone today who > mentioned a recently committed module is being used by foreign researchers. > A number of us have made efforts to grow the Climate user base and I think > we need to be very sure that no-one is using the codebase before stating > explicitly that no-one does. > > >> I’m going to make a scary suggestion. Push all the code! > > > Really ;) > > >> Do >> things! Talk on the dev list. Figure out how not to piss >> people like Kyo off and gain their contributions even if it means >> breaking some tests, compromising (Kyo too), but people on all sides. >> > > Chris I think we are all for doing things. I hope we are getting to a > stage now where we will unearth what it is that is pissing Kyo off. We all > have an obligation as part of the PMC to support his with any committer and > developer resources he requires. This includes potentially guiding him > towards development neutral lists such as community@/community-dev@, etc. > I can't provide help to someone if I don't understand where the > pain/frustration stems from. > > >> >> Sorry but PMC lead is no more special than any PMC member. > > > No-one said he was AFAIK. My point was that Mike was engaged in a primary > development role of OCW. Whereas others were/are not. > > >> The person >> has an added responsibility of filing a board report and being the >> eyes and the ears of the board. I haven’t seen it come across that there >> is a concern that he’s merging everything. I have a concern. I’m bringing >> it up. >> > > As you are entirely entitled to do. We are by no means at crisis point > here. There are issues which need addressing with regards to this topic. > I've TBH never seen a PMC with 29 members and only 1 person merging code. > > >> This PMC will have succeeded when Kyo Lee has merged and committed his own >> code to the repo. It will succeed when Mike’s not committing everyone’s >> PRs. >> > > Sounds like a sure aim to me. It is not difficult. All Kyo needs to do is > as follows > > $ cd climate > $ git remote add apache > https://git-wip-us.apache.org/repos/asf/climate.git > $ git push apache $branch > > > It would be real nice if you could try out a test commit Kyp to see if you > are able to do so. > > >> >> > >> >I would suggest that we augment the workflow to accomodate a thirst step >> > >> >3) Please make best efforts to at least consider other community comments >> >before merging. This way we can work collaboratively to all have a better >> >understanding of the codebase. >> > > > > Do you Chris or does anyone else have an opinion or suggestion for > augmenting the workflow or abolishing it altogether as the above thread > would suggest? > I think regardsless of what we end up deciding upon, we need to have it in > black and white on the wiki. It seems like this has become a major pain > point for Kyo less a major concern for Chris as a champion of the project > and ongoing mentor. > I would like to work together to establish a resolution. Kyo, it would > mean A LOT if you were part of this. This also goes for the other ~25 PMC > members. OCW is a significant imbalance in the community with regards to > development Vs ML correspondence and physical ML presence. An observation > and inference on my part is that this is the result of many people > basically not having the time and or cycles to actively discuss or develop > OCW in line with their day-to-day operations. This is not due to an overly > convoluted commit process. The fact that Kyo is struggling is our primary > cause for concern as loosing a valuable community member is literally a > disaster no matter what the community is and how many individuals are > associated with the community. > > Any comments folks? > Thanks Chris for your comments. > Lewis > -- *Lewis*
