On Wed, Oct 5, 2016 at 5:13 PM, Daniel Kulp <[email protected]> wrote:
> I just want to give a little more context to this…. I’ve been lurking on > this list for several months now reading everything that’s going on. From > Apache’s standpoint, that should be a “very good start” for getting to know > what is happening in a project. > > On my last PR, Eugene commented about using the AutoValue pattern for part > of it which caught me off guard. None of the other IO’s in master were > using it, there wasn’t any discussion on this list about it, I had no idea > what it was about. So I asked JB to make sure I hadn’t missed anything. > > Anyway, this is one of the main concerns I have with Beam’s PR work flow, > I feel I’m missing things as there is significant amount of things not > happening on a list. The initial pull request is going to the commits > list (ok, would prefer the dev list, but at least its on a list). However, > none of the comments or discussions or anything that is occurring as part > of the review is making it to any list. The only people that “learn” from > the reviews are the reviewers and the person who initiated the PR unless > they go into each and every PR and read the comments (and find the news > ones and such). With my Apache hat on, this bothers me. Anyway, I don’t really understand why the full github integration wasn’t > setup for the beam PR’s so that the comments would come back to the lists > as well (and JIRA, BTW). > This part confuses me. We've been told that discussions on JIRA, even though they are emailed to the mailing lists, don't count as happening on the mailing list. So why would github integration be helpful vs just more spam? As another example, the comments on PR1003 are very applicable to anyone > looking into writing IO’s and they could learn about some of the “best > practices” presented there. As Beam grows during its incubation, we are moving a lot of knowledge to documentation, but yes -- right now, most of the I/O related practices live in Eugene's and my head (and now, JB's!). We're working on it, and hope to dramatically improve documentation for source authors in the next quarter. For AutoValue specifically, this is by no means codified and it is DEFINITELY not mandatory. Eugene and JB just experimented with it in the last few days and decided it was useful in a few cases. We do (or did, before this thread) need to have an actual discussion on the mailing list before moving forward further towards making it policy. Right now Ben Chambers is trying to apply AutoValue in places that need templated types and struggling with multiple ?s, so the discussion may need to continue! ... Thanks, Dan That’s basically the background as to why JB sent this. I was confused and > bugged him. :-) > > Dan > > > > > On Oct 5, 2016, at 1:51 PM, Jean-Baptiste Onofré <[email protected]> > wrote: > > > > Hi team, > > > > I would like to excuse myself to have forgotten to discuss and share > with you a technical point and generally speaking do a small reminder. > > > > When we work with Eugene on the JdbcIO, we experimented AutoValue to > deal with IO configuration. AutoValue provides a nice way to reduce and > limit the boilerplate code required by the IO configuration. > > We used AutoValue in JdbcIO and, regarding the good improvements we saw, > we started to refactor the other IOs. > > > > The use of AutoValue should have been notice and discussed on the > mailing list. > > > > "If it doesn't exist on the mailing list, it doesn't exist at all." > > > > So, any comment happening on a GitHub pull request, or discussion on > hangouts which can impact the project (generally speaking) has to happen on > the mailing list. > > > > It provides project transparency and facilitates the new contribution > onboarding. > > > > Thanks ! > > > > Regards > > JB > > > > -- > Daniel Kulp > [email protected] <mailto:[email protected]> - http://dankulp.com/blog < > http://dankulp.com/blog> > Talend Community Coder - http://coders.talend.com < > http://coders.talend.com/> >
