OK, well my bad on trying to steer this in a particular direction. I just think everyone needs to work together on this more.
I’ll stand down. Kyo my #1 goal for you and anybody is reducing barriers for committing. Sorry for the tone of my emails. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: <Lee>, "Kyo (329C-Caltech)" <huikyo....@jpl.nasa.gov> Reply-To: "dev@climate.apache.org" <dev@climate.apache.org> Date: Tuesday, May 12, 2015 at 11:32 PM To: "dev@climate.apache.org" <dev@climate.apache.org> Subject: Re: Project Workflow >Hi Mike, > >Yes, I won¹t hesitate to ask your help. Thank you as always. > >Hi Cam and everyone, > >I would like to clarify that the time wasting discussion is not about the >project workflow at all. >I am sorry, but I have been too busy to read any email thread on the >workflow. > >The discussion in my email is about the github pull requests. > >https://github.com/apache/climate/pull/196 >https://github.com/apache/climate/pull/197 > >I wish I do not have to stay up until 2 AM just to explain simple seasonal >mean calculation repeatedly. > > >Kyo > > > >On 5/12/15, 10:54 PM, "Michael Joyce" <jo...@apache.org> wrote: > >>Beyond my comments below I'm stepping off this thread. It's become too >>toxic for my liking and most of the "discussion" on here is helping >>nothing. >> >>I think getting feedback on our current workflow would be great. If you >>have ideas anyone please do respond (or maybe just make a new thread) so >>we >>can talk about stuff. It's important that we make it work for us! >> >>@Kyo, I've said it a million times, but it's important to say it again. >>If >>you need help with anything please don't hesitate to reach out. I'm >>always >>happy to help out when I can. You always have this list, you know where >>my >>office is, you know what my phone number is, and you have me on IM. If >>you're ever unsure about something or just need an extra pair of eyes to >>find a bug please ask. >> >>-- Jimmy >> >>On Tue, May 12, 2015 at 9:53 PM, Mattmann, Chris A (3980) < >>chris.a.mattm...@jpl.nasa.gov> wrote: >> >>> Lewis, >>> >>> -----Original Message----- >>> >>> From: Lewis John Mcgibbney <lewis.mcgibb...@gmail.com> >>> Reply-To: "dev@climate.apache.org" <dev@climate.apache.org> >>> Date: Tuesday, May 12, 2015 at 8:29 PM >>> To: "dev@climate.apache.org" <dev@climate.apache.org> >>> Subject: Re: Project Workflow >>> >>> >Hi Chris, >>> >Please see replies inline >>> > >>> >On Tue, May 12, 2015 at 6:10 PM, <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. >>> >>> Yes me saying I don¹t know what you are talking about is my way >>> of saying I disagree with you. That clear? >>> >>> > >>> > >>> >> 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. >>> >>> Please, provide me a citation for this? Which PR has done >>> that? Be specific too. Don¹t say ³the PMC². Use names, and PR #s. >>> >> >>Not to speak for Lewis but I assume >>https://github.com/apache/climate/pull/195 >>Although that PR seems to perfectly represent receiving good feedback and >>making quick changes to issues that broke the build and getting >>everything >>resolved. Seemed like great collaboration to me. >> >> >>> >>> >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. >>> >>> Who in the world is suggesting we merge things that break 50% of the >>>code? >>> I¹m suggesting *we* actually merge things. Instead of having one person >>> merge >>> things. And mostly have others talk about how they want to merge things >>>and >>> then have one person end up merging things. After lots of discussion. >>> >> >>Saying it again for the billionth time. With regards to helping merge >>stuff, please do. >> >> >>> [..snip..] >>> > >>> > >>> >> 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¹m raising it, b/c honestly, this PMC has failed to educate at least >>>one >>> of its members on his rights. And I am telling you that as the Champion >>>of >>> this project and the person who even suggested bringing it here, it¹s a >>> collective >>> issue. I did my part to try and educate that person today at the coffee >>> cart, >>> by telling Kyo this at JPL - I also noted this on the recent PR #: >>> >>> http://s.apache.org/to1 >> >> >>Kyo was on the original team when the project went into incubator >>correct? >>Seems like that certainly should have been brought up at some point. >>Don't >>know if it's fair to say that the PMC failed to educate someone who has >>been on the PMC since it started. I wouldn't think to check that with >>people honestly. Perhaps we should make sure the current list of people >>are >>aware of what's going on if this is an ongoing concern? There's certainly >>a >>decent number of people on the PMC who aren't from a software background >>so >>that might be useful. >> >> >>> >>> >>> >>> >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. >>> >>> Realize in CTR - they can do the same thing. We are using a version >>>control >>> system. Since when has code committed to a version control system been >>> something >>> that¹s difficult to revert? You can do the exact same thing in CTR. >>>With >>> less >>> barrier. Want more barrier, RTC? Use it then. Then later do CTR. It¹s >>>easy. >>> >>> > >>> > >>> >> 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@. >>> >>> You¹re conflating the issue. This isn¹t a question of Github versus >>>JIRA. >>> This is a question of {Github, JIRA, auto whatever} versus {regular old >>> dev mail}. >>> >>> > The reason I say that is that (with my experiences >>> >of mentoring Apache Usergrid) communities should not be *forced* to >>>use >>> >Jira over Github. >>> >>> I¹m not suggesting that. >>> >>> > 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? >>> >>> Balance of course. Important development decisions and discussions >>>should >>> not be in a Pull Request conversation - it should be on the dev list, >>>not >>> surrounding by a message saying ³Github notification from user XXXYYY². >>> Small discussion around an issue on Github? Tests passed from a bot? >>> Sure leave that on Github. ³I don¹t think X is a good implementation >>>over >>> Y² - that¹s dev list conversation *not* surrounded and marshaled by an >>> automated bot. >>> >>> > >>> > >>> >> >>> >> 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. >>> >>> Please read what you just said. I have to wait 72 hours, then it¹s >>>cool. >>> But >>> before 72 hours it¹s cool too. Huh? >>> >> >>The 72 hours is a cursory period that I said was my personal metric. >>Please >>check the OP again. There seems to be some confusion about this. >> >> >>> >>> > 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. >>> >>> Guess who suggested making that pre-commit build and told MikeJ to look >>>at >>> the way Spark did it? You¹re not telling me anything I don¹t already >>>know >>> Lewis. >>> >>> >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. >>> >>> Citations? Were they self patches from Mike to himself? Were they Mike >>>and >>> Kim >>> who clearly seem to agree with each other - Kim committing Mike¹s >>>patches >>> or >>> vice versa? >> >> >>> > >>> >[..snip..] >>> > >>> > >>> >> 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. >>> >>> What is to guard against? That¹s my question. What precisely are we >>> guarding >>> against? Do we not trust the version control system? What users have >>> complained >>> about a broken build thus far? Please name a user, not a developer. >>> >>> > >>> >[..snip..] >>> > >>> > >>> >> 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. >>> >>> That¹s the problem - no he can¹t. You can¹t have it both ways. If PMC >>> has a 72 hour wait period then there is a barrier to him committing >>> whenever >>> he likes. If he must discuss everything there is a barrier to him >>> committing >>> whatever he likes. >>> >>> So, which is it? >>> >> >>Open PR, wait a reasonable amount of time for people to check stuff out, >>merge it. That's the workflow. "Reasonable amount of time" is at the >>discretion of the person getting on and deciding to merge stuff. 72 hours >>was my personal goto that was listed as an example in the OP. >> >> >>> Here¹s my proposal. We start *TRUSTING* each other, and start >>> doing things and moving forward instead of worrying about PR discussion >>> and broken tests, and pointing people to read workflow wiki pages (that >>> you seem to be citing, but have stated you haven¹t read later on in >>>this >>> email) that reference Github as the canonical source. >>> >> >>Again. Where does it say this? Because I just read through it again and >>can't find what you're talking about. >> >> >>> > >>> > >>> >> , 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. >>> >>> Huh? You are citing the ³workflow² earlier - have you read it or not? >>> >>> > >>> >[..snip..] >>> > >>> > >>> >> 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! >>> >>> This is not a Github problem. It¹s a community problem, that includes >>> issues with Github, amongst others. Github has worked great on Nutch >>>and >>> Tika - and in certain interaction types that I¹m not seeing on OCW >>>lately, >>> it could work well too. I¹m calling out things I don¹t think are >>>working >>> well. >>> >>> > >>> > >>> >> - 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? >>> >>> Strawman. >>> You: Are you citing a problem with X, so let¹s do ^X. >>> >>> Ever heard of gradients that lie in-between? >>> >>> >[..snip..] >>> > >>> > >>> >> 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. >>> >>> >>The instructions on how to merge are in that wiki document that is >>constantly cited in this thread right below how to make a pull request. I >>haven't seen any emails about being confused so I'm not certain why >>people >>would assume people are confused? >> >> >>> They would if they knew how, and weren¹t afraid that the PR they filed >>> would get 5-6 suggestions before committing a simple date/time >>>function. >>> C¹mon. >>> OCW is not Nutch. It¹s not Hadoop. Let¹s use Software Metrics and do a >>>full >>> SLOC count and let¹s put it Ohloh and see how many proposed developer >>>hours >>> have been invested in it versus Nutch and/or Hadoop and/or Tika, etc. >>>It¹s >>> not >>> even close. >>> >> >>Also, OCW is already on Ohloh but they have some issues with their repo >>updates. I gave up a long time ago trying to get them to refresh their >>stuff. Unfortunately they weren't very responsive. All the login info was >>sent to private@ a long time ago I'm pretty sure. If you cant find it let >>me know, I'm sure it's around somewhere. >> >> >>> >>> You have to be able to adapt in projects and to be able to lower the >>> barrier >>> when necessary - I absolutely understand in Nutch having 1 or 2 >>>iterations >>> sometimes on patches and on PRs and stuff. We have 5-6 interested >>> developers >>> doing things right now - and iterating and PRs and stuff and >>>conversation >>> is >>> a great way in a distributed team across timezones and so forth to work >>> together. >>> We have nowhere near that situation with OCW right now. The active >>>people >>> working on >>> OCW are all in the same time zone; 100% all work for the same company, >>>and >>> of which there is 1 primary active developer; with 1 or 2 occasional >>> developers >>> in terms of contributions that submit things that are merged by the 1 >>> primary >>> active developer. >>> >>> >>> > >>> > >>> >> 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. >>> >>> Red-herring. >>> >>> They are not contributing to the project right now. >>> >>> >>> >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! >>> >>> This ignores the heritage of contributions that existed long >>> before Mike Joyce. >>> >>> >[..snip..] >>> > >>> > >>> >> 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. >>> >>> It¹s all on the Github - treating people like we trust them involves >>>taking >>> a leap of faith sometimes on what they are doing. And trusting it¹ll be >>>OK. >>> That¹s my impression reading the Github. You may disagree. >>> >>> >[..snip..] >>> > >>> > >>> >> 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. >>> >>> >>> Stop citing good software coding practices. It¹s community >>> over code here at the ASF. I studied software architecture and >>> development and understand plenty about it. >>> >>> I want to reduce Kyo¹s frustration about contributing to the codebase. >>> He has stated all the discussion before being able to make a simple >>>commit >>> causes his frustration. I agree with him and think there is too much >>> discussion >>> before a commit. I¹m a PMC member on the project. >>> >>> > >>> > >>> >> >>> >> 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. >>> >>> Again, please tell how I am suggesting directly to ignore Jenkins >>> considering >>> I suggested to have Mike copy the Spark one and create it. Please tell >>>me >>> precisely how I am suggesting to ignore Jenkins? I¹m suggesting to >>>trust >>> each other. HUGE difference. >>> >>> > >>> > >>> >> 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. >>> >>> Where are they in the last 9 months on the list? The last year? >>> If they are out there, I would welcome them here. Right now I can >>>safely >>> say >>> having been on this project for a long time and monitoring the list >>>that >>> not a >>> single non JPL email has been sent to the list in months related to any >>> external >>> users of the software. >>> >>> >>> >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. >>> >>> Please make a list of known users of the code base that aren¹t using >>> Jinwon¹s >>> forked version. I would seriously like to know, having been one of the >>> principal >>> people to help start this project, and also present on it >>>internationally >>> for >>> years before it even came to the ASF. >>> >>> If you have such a list that isn¹t students who aren¹t on the list, I >>>would >>> love to see it. Users bring desire for releases, and new features, and >>>use >>> cases >>> and I haven¹t seen any of that at all brought on to this list. There is >>>NO >>> ONE >>> that would love more users for OCW than me. Period. I brought the >>>project >>> here, >>> don¹t suggest for a second and I take extreme offense to your attempt >>>to >>> try >>> and educate me on the users. If you know about the users, please >>>produce a >>> list >>> and don¹t speak in generalities. >>> >>> >>> > >>> > >>> >> 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. >>> >>> Lewis, newsflash, I¹ve unearthed it. See all my emails and commentary. >>>See >>> Loikith¹s email. That¹s why. That¹s why I¹m bringing this up. >>> >>> >>> > 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. >>> >>> I do. For all the reasons stated above. >>> >>> > >>> > >>> >> >>> >> Sorry but PMC lead is no more special than any PMC member. >>> > >>> > >>> >No-one said he was AFAIK. >>> >>> direct quote from you is that Mike was the ³PMC Lead². So not sure >>> why you used that term - so I was following from that. >>> >>> > My point was that Mike was engaged in a primary >>> >development role of OCW. Whereas others were/are not. >>> >>> Bingo. Which is precisely my problem with this. One developer engaged >>> in the primary development role of a project at Apache is a serious >>> concern. >>> >>> > >>> > >>> >> 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 is a precise concern point, among others that I¹ve raised. >>> >>> > >>> > >>> >> 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 >>> >>> You missed the part about 5-6 conversations and comments with two other >>> people >>> that seem to agree to disagree with him. Or to suggest that he do 5-6 >>> things >>> before he commit the code. With a project with this low activity, >>>isolated >>> to >>> a single developer, it¹s a recipe for disaster. I¹m wondering how you >>>are >>> having >>> a hard time seeing that? >>> >>> > >>> >> >>> >> > >>> >> >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. >>> >>> Uhhh, yes. I¹ve suggested it. >>> >>> Be flexible. Trust each other. YMMV. >>> >>> >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. >>> >>> Disagree. It¹s a combination of both. The way you can attract new >>> contributors >>> is to revisit and deal with a process that has any barriers (even 1 >>> barrier) >>> and try and have none. Some Apache projects accept patches today from a >>> mailing >>> list (HTTPD) - still to this day - and credit those contributors >>>without >>> giving >>> them 5 or 6 elements in the ³Bring me a rock game² for them to do >>>before >>> committing >>> their patch. >>> >>> Code can be continuously adapted and updated (CTR); can be peer >>>reviewed >>> before >>> commital (RTC); and these models can work and do work well and nicely >>>with >>> one >>> another. >>> >>> >>> >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. >>> >>> It¹s even more than that. Kyo, as a PMC member, is also indicative of >>>the >>> larger set of scientists that need to use OCW and to moreover to >>> contribute to it. >>> He¹s having problems doing both. >>> >>> Cheers, >>> Chris >>> >>> >
