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
