On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran <ste...@hortonworks.com> wrote:
> > > On 11 Nov 2015, at 09:38, Bertrand Delacretaz <bdelacre...@apache.org> > wrote: > > > > Hi Steve, > > > > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran <ste...@hortonworks.com> > wrote: > >> ...is JIRA-first development conducive to developing a community?... > > > > I don't think so, as you say this breaks the project into very small > > buckets and it's very hard for someone new to get the overview of > > what's going on and what the big ideas and visions are. > Agreed. I also find it sad that work is *gated* by using Jira first. We should be trusting our peers, let them commit changes necessary, and review their work afterwards. Trust is the basis of a healthy community, and RTC (via Jira or otherwise) just screams "we don't trust you. we must review all commits first." >... > One of the troublespots is those "minor" patches which have traumatic > consequences; you don't notice when the issue is created, don't watch it, > and then, when its merged in, you discover that things now behave > differently. Anything related to specific dependency updates are things to > watch there (guava, jackson, jersey), but it could be something more subtle > like a change in the concurrency model of some bit of code. It's only later > that you find your code has stopped working and you are left trying to work > out what happened and why. > I'm not sure what the above has to do with issues/Jira. Any commit can have this effect, whether it was done directly or via an issue. It's just a typical problem with development. (and yeah, it leads into a whole separate conversation about testing and CI) >... > Noted, but we're going to try it in the slider dev group anyway, so we can > do some more detailed code review of various complex things more > interactively. I know it excludes people who can't be there, but its still > more inclusive of > I see no problem doing code reviews this way, as other devs can still comment/review whatever output gets committed. They're only "shut out" of the first review, not ALL review. Using them for initial code development or decisions? Not so much. Using them to reach a consensus among a subset of the community? Sure, and bring that result to the dev@ list to reach full community consensus. We see this done all the time with hackathons: the group at the 'thon come up with some idea they all like, and bring that to the dev@ list. 10 people think it is the right approach and share it, then rope in the other 10. >... Cheers, -g
