OK, I filed https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-11797 to create a new reviews@ list
On Mon, May 2, 2016 at 12:56 PM, Chris George <[email protected]> wrote: > +1 for splitŠ I already have email filters to catch the gerrit stuff > though, but I can see the reasoning behind splitting it. > > On 5/2/16, 1:40 PM, "Jean-Daniel Cryans" <[email protected]> wrote: > > >I'm +0 with the split. > > > >On Mon, May 2, 2016 at 12:38 PM, Todd Lipcon <[email protected]> wrote: > > > >> Seems like there's a mix of opinions, but Adar and Mike wrote the > >>longest > >> replies and I don't feel too strongly, so let's go with a separate list. > >> I'll give another few hours in case anyone wants to make a last plea for > >> the other option, and then file a JIRA to create the new ML. > >> > >> -Todd > >> > >> On Tue, Apr 26, 2016 at 6:08 PM, Mike Percy <[email protected]> wrote: > >> > >> > My preference is for a separate list, but if others feel strongly the > >> other > >> > way then no big deal. > >> > > >> > Selfishly, I'd prefer reviews@ so that I can continue subscribing to > >> JIRA > >> > how I do now and still have the option of getting all of the review > >> traffic > >> > (separately). Other potential contributors may feel the same way > >> (however, > >> > it is more complex to have so many lists to subscribe to). > >> > > >> > I can see how it could be useful for someone to have a single search > >> index > >> > for both reviews and issues, but I'm not personally excited about it, > >> since > >> > I already get that through GMail as a subscriber. > >> > > >> > Mike > >> > > >> > On Tue, Apr 26, 2016 at 1:51 PM, Adar Dembo <[email protected]> > wrote: > >> > > >> > > I can see how that could be useful, but it's not really what I need > >> when > >> > I > >> > > search through a project's mailing list archives today. Bug reports > >>are > >> > > usually high-level enough that I can grok them, but implementation > >> > details > >> > > (i.e. code reviews) are too much and I'd prefer to exclude them. > >> > > > >> > > As for Kudu itself, well, I wouldn't use the mailing list archives > >> > anyway, > >> > > because I understand the details and also know how to go straight to > >> the > >> > > source of truth (i.e. JIRA for bug reports, gerrit for code > >>reviews). > >> > But I > >> > > imagine folks less familiar with a project would feel the way I do: > >>bug > >> > > reports may be understandable, but code reviews are too detailed. > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > On Mon, Apr 25, 2016 at 9:52 PM, Todd Lipcon <[email protected]> > >> wrote: > >> > > > >> > > > On Mon, Apr 25, 2016 at 2:15 PM, Adar Dembo <[email protected]> > >> wrote: > >> > > > > >> > > > > As you mentioned, my vote is for a new mailing list to capture > >>code > >> > > > > reviews. My arguments are: > >> > > > > 1) It's more predictable for newcomers (JIRA to issues@, gerrit > >>to > >> > > > > reviews@, > >> > > > > etc.). > >> > > > > 2) It's friendlier to mailing list archivers, where the search > >> tools > >> > > > often > >> > > > > aren't great and separation of issues from code reviews > >>simplifies > >> > > > 'manual' > >> > > > > searching. > >> > > > > > >> > > > > > >> > > > But if you're searching, wouldn't you want to see results from > >>both > >> > code > >> > > > reviews and bug discussion, given a lot of bug details end up in > >> commit > >> > > > messages and code review conversation? > >> > > > > >> > > > > >> > > > > > >> > > > > On Mon, Apr 25, 2016 at 11:19 AM, Jean-Daniel Cryans < > >> > > > [email protected]> > >> > > > > wrote: > >> > > > > > >> > > > > > I'd be in favor of using issues@, and only create reviews@ if > >> > folks > >> > > > > > complain it's still not good enough. > >> > > > > > > >> > > > > > J-D > >> > > > > > > >> > > > > > On Mon, Apr 25, 2016 at 11:00 AM, Todd Lipcon > >><[email protected] > >> > > >> > > > wrote: > >> > > > > > > >> > > > > > > We discussed this a month or two ago but I've been > >>delinquent > >> in > >> > > > > pushing > >> > > > > > > this forward. We all seemed to agree that it would be good > >>to > >> > move > >> > > > the > >> > > > > > > gerrit traffic off of dev@ so that the list is easier to > >> > subscribe > >> > > > to > >> > > > > > and > >> > > > > > > follow for newcomers who might not be interested in every > >> > revision > >> > > of > >> > > > > > every > >> > > > > > > patch in flight (100+ emails/week). But, we didn't quite > >>settle > >> > > where > >> > > > > to > >> > > > > > > move it *to*. > >> > > > > > > > >> > > > > > > There were two options: > >> > > > > > > > >> > > > > > > 1) use the existing issues@ list > >> > > > > > > 2) use a new reviews@ list > >> > > > > > > > >> > > > > > > My preference is towards using issues@ because oftentimes > >>when > >> > > > someone > >> > > > > > is > >> > > > > > > fixing a bug or making a small improvement, they don't > >> > necessarily > >> > > > > > create a > >> > > > > > > new JIRA. So, I'm not sure why someone would want to > >>subscribe > >> to > >> > > > just > >> > > > > > JIRA > >> > > > > > > but not gerrit (or vice versa). Given that Gerrit already > >> > provides > >> > > an > >> > > > > > easy > >> > > > > > > filtering mechanism (eg 'kudu-cr' in the subject line) > >>people > >> can > >> > > > > always > >> > > > > > > separate them back out. > >> > > > > > > > >> > > > > > > Adar mentioned that he prefers reviews@ to be more > >> 'consistent', > >> > > > > though > >> > > > > > > I'll let him pipe up with his rationale. > >> > > > > > > > >> > > > > > > I don't think we need a formal vote, but opinions solicited! > >> > Would > >> > > be > >> > > > > > great > >> > > > > > > to wrap this up this week so we can report the progress > >>back on > >> > our > >> > > > > > > upcoming podling report. > >> > > > > > > > >> > > > > > > -Todd > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Todd Lipcon > >> > > > Software Engineer, Cloudera > >> > > > > >> > > > >> > > >> > >> > >> > >> -- > >> Todd Lipcon > >> Software Engineer, Cloudera > >> > > -- Todd Lipcon Software Engineer, Cloudera
