Alex, Yes. Pretty much any project that has significant commercial applications will have cadres of developers from companies involved. Those companies will be managing those developers time and efforts to meet the company goals.
This can definitely be pernicious, especially since a company may be making decisions about which general areas they want to be pushing off-line. This affects the project majorly even if the technical and coding decisions are made in good fashion. Another problem is that when some developers are working 40 hours per week plus on a project, volunteer developers often have a very hard time keeping up with the pace of change. Building safe havens not only for different timezones but also for different time rates is an architectural challenge that is well worth doing. One way to do this is with very clean user-defined-function sorts of architectures. That can help moderate the rate of change. On Wed, Nov 11, 2015 at 10:16 AM, Joe Witt <joe.w...@gmail.com> wrote: > "Trust is the basis of a healthy community" > > -- For sure. > > "and RTC (via Jira or otherwise) just screams "we don't trust you. we > must review all commits first."" > > -- I disagree. RTC has merit independent of concerns of trust. If > trust issues are present in a community then any number of challenges > will exist and all processes will suffer. Keep in mind RTC applies to > everyone (PMC, committer, contributor). So it isn't about trust at > all. It is about community. > > Not wanting to sidetrack this thread but also didn't want that comment > to go without a counter. > > Thanks > Joe > > On Wed, Nov 11, 2015 at 12:59 PM, Greg Stein <gst...@gmail.com> wrote: > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
