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 > > >
