How about sending just the notifications for creating new JIRA and opening PR to dev@ so that those that are interested can start watching?
Thanks, Thomas On Wed, Oct 5, 2016 at 5:33 PM, Dan Halperin <dhalp...@google.com.invalid> wrote: > On Wed, Oct 5, 2016 at 5:13 PM, Daniel Kulp <dk...@apache.org> 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é <j...@nanthrax.net> > > 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 > > dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog < > > http://dankulp.com/blog> > > Talend Community Coder - http://coders.talend.com < > > http://coders.talend.com/> > > >
