Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> more information about project split


Copy link to this message
-
Re: more information about project split
+1 for (4). I agree with Doug that JIRAs are often used for discussion. I
wouldn't mind getting the Hudson reports excluded (wow, what a surprise! -1
for failed tests in contrib), but otherwise, I enjoy how having JIRA send
emails pushes many folks to consolidate discussions on the JIRA instead of
in email.

On Tue, Jun 23, 2009 at 10:47 PM, Dhruba Borthakur <[EMAIL PROTECTED]> wrote:

> +1 for (4).
>
> This means that the default settings for a hadoop developer is to get
> eveyrthing via email. This allows anyone to set filter settings on his/her
> own email reader to prioritise which types of emails one would like to
> process-in-depth.
>
> -dhruba
>
> On Tue, Jun 23, 2009 at 8:39 PM, Amr Awadallah <[EMAIL PROTECTED]> wrote:
>
> > +1 for (2)  [assuming jira here means a separate mailing list that gets
> the
> > full jira traffic]
> >
> > My main reasoning is: not all issues are relevant to all people, so we
> > should let folks select which issues they want to stay fully updated on
> > (that is why JIRA has the watch functionality). For those who want to
> keep
> > track of every single jira update going on then they can join the full
> > traffic list. I think that is a good compromise between both worlds. My 2
> > cents.
> >
> > -- amr
> >
> >
> > Doug Cutting wrote:
> >
> >> Owen O'Malley wrote:
> >>
> >>> I think the community is better served by having a mailing list that is
> >>> dominated by people posting rather than a deluge of jira traffic.
> >>>
> >>
> >> This is a somewhat false dichotomy: Jira messages are postings by
> people.
> >>  Folks should not make changes in Jira without realizing this. This is
> one
> >> reason why I've long advocated that we should remove the ability for
> folks
> >> to edit Jira comments or for anyone but admins to remove Jira comments.
>  If
> >> we disable emails then this becomes even more essential: folks should
> not be
> >> able to re-write project history.
> >>
> >> Jira actions are project actions, and the Apache convention is that
> >> project actions should be logged on public mailing lists.  We should
> change
> >> that policy cautiously and only after consideration.
> >>
> >>  Choices:
> >>>  1. create/resolve/close to dev
> >>>  2. create/resolve/close to dev, others to jira
> >>>  3. create/comment/resolve/close to dev
> >>>  4. all to dev
> >>>
> >>> The problem with 3 is that you can add comments on most of the actions.
> >>> So either you capture all events or you only capture part of the
> comments.
> >>>
> >>
> >> (4) Send create/resolve to -dev and all others to -issues (a new list)
> >> plus prohibit all comment edits and permit comment deletion only by
> admins.
> >>  (Closing is not generally interesting, since it's only done to seal an
> >> issue once its included in a release.)
> >>
> >> +1 for (4)
> >>
> >> Doug
> >>
> >
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB