Lewis, I’m honestly not sure what you are talking about, and to be honest, waiting 72 hours before committing everything is not a project I’d ever want to be on. 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. It shouldn’t be *imposed on me*. 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.
More below: > >> >> I don’t think we should dictate everything be code reviewed. > > >72 hours seems pretty permissive to me. I would comment that I see it as a >different case where comments are provided and not addressed. I also don't >think that we've seen anything that is so urgent that it cannot withstand >a >72 grace period. Is this unreasonable? 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. Things that are big changes, controversial, sure, get feedback from others. 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’ve >> seen this directly lead to conversations that are relevant to >> development being buried in Github. > > >I believe that the issue being referenced here has to do with PR's >stagnating due to suggested improvements not being accommodated. Is this >not the case? This is what I read. 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. And Kyo not even knowing that he has direct commit access to the Git repo at the ASF, 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). > >> Take for example your and >> Whitehall’s conversation(s) with Kyo that I doubt anyone here has >> ever seen since they aren’t even commenting on the Github. Yes, >> Github emails are sent to the dev list, my guess is that people >> ignore them. >> > >I get batch emails to the ML. This saves me major headache and sometimes >it >takes a wee while to go through everything. In terms of reading them... >yes >I do. I read them like I read any other ML message. If and when I can. If >I >feel it appropriate to comment on GH I will. Likewise, if I feel it >appropriate to comment on ML I will. How many other people are getting batch emails? 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. 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 - 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. > > >> >> On the code review issue - Kyo (or others) shouldn’t have to endlessly >> debate or discuss the advantages or disadvantages of this or that >> before simply pushing code, and pushing tests. > > >I don't know if anyone is endlessly debating thing are they? I mean there >are some community suggestions which have gone unanswered for months. What are community suggestions? 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. Yes I said it. Is Mike the merge master? Has he thrown up a VETO on Kyo’s code? What about Whitehall? What about you? That’s about the only thing that can stop him from committing to the code base directly. 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 >would lead me to draw the conclusion that there is a strong attempt to >obtain consensus but that this cannot be done in a silent manner. There >needs to be correspondence on what is the right thing to do. We've all had >patches which take months to get in to a codebase. We've all got loads of >examples lying around. I don't really see thsi as a biggie. What I do see >is a biggie is that a consensual approach is what will work best for OCW >community. I don’t think it’s working well. In fact, I know it isn't. See referenced email from Kyo. He’s finding it difficult to contribute. 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? > > >> My general rule of >> thumb is that there are CTR and RTC workflows and use cases for >> both. RTC works great when it’s possibly controversial or when you >> really want someone’s eyes on your code for review. However it’s >> also overhead that I do not believe is needed if a developer wants >> to push forward and scratch his or her itch, in an area of the >> codebase that they are working on. The codebase is factored out >> enough reasonably well so that people can work on things in parallel >> and independently. When in doubt, ask. >> > >Absolutely. I don't see that 72 hours block this in any way shape or form. >Does anyone else? I do. It’s too long. Please let me know the sacred vow that breaking a test on OCW causes. We have 0 users of the project. We are our own users. I’m going to make a scary suggestion. Push all the code! 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. > > >> >> I’m also pretty worried since anyone that looks at the Git and >> project history over the last year can easily see that Mike has >> pretty much been doing the bulk load of the pushing and code >> committing here. > > >Yep. Mike has been merging for people. Committing a bunch himself (after >usually waiting the 72 hours) and also PMC lead with a vetted interest in >mapping OCW directly to his day-to-day job so this would make logical >sense >to me. I share your concern however it is no surprise to me that the stats >tell the tale they do. Sorry but PMC lead is no more special than any PMC member. 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. 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. > > >> Kim’s stepped up recently as has Kyo, which is >> 3 people, which is great, but I’m worried about a project with >> a small number of active developers (really 1 major) imposing >> RTC - I don’t have time to look up citations but you are free >> to scope these out over the ASF archives. > > >If 72 hours grace period (because that's what I see it as coming down to) >is too long then we need to seriously consider why. See above. > > >> RTC on smaller projects >> just leads to barriers. We need to be flexible and make it inviting >> for at the very least, our own developers to contribute to the project, >> let along attracting new people. > > >The workflow has 2 steps. >1) Log an issue and provide a PR >2) Wait 72 hours before committing (lazy consensus). > >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. > > >> Ross was elected in December 2014, >> which is great, but we need to do better. >> >> >Certainly. OCW fills a very niche area though which we are all aware of. >It >is a non-traditional Apache project filling one of few pure science >oriented TLP's. >The fact that there are few committers on the project is not to me any >huge >surprise either. Not everyone is working with scientific data. If you are >not then you have absolutely no incentive to use OCW. >Additionally, if we have a problem with community outreach then I say we >should make an attempt to address that on it's own. Lets be careful not to >munge these issues into one... simply because they are not. >If the two stage workflow is not working or if it is causing barriers then >we need to address it. I am struggling to see how it can be causing >barriers. The issues may be that there needs to be clarification on >implicit expectations which come bundled within those two stages. > >Hopefully I've communicated some of my points here. Lets kep this going. >Thanks >Lewis Cheers, Chris
