accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billie Rinaldi <bil...@apache.org>
Subject Re: Accumulo 1.6 and beyond feature summit
Date Fri, 01 Feb 2013 15:49:20 GMT
On Fri, Feb 1, 2013 at 7:22 AM, Adam Fuchs <scubafuchs@gmail.com> wrote:

> How I read Benson's comment is that if anyone feels excluded by the online
> forum and voices that objection then we should not do it. This is not to
> say that the community has any power to forbid communication about Accumulo
> outside of email channels, but we should make things as accessible as
> possible and only make official decisions via approved channels (do we have
> by-laws to approve channels yet?).
>

We should work on our by-laws.  I believe the only channel we have to make
decisions is through the mailing list (and by extension JIRA, since it is
logged to the mailing list).

Billie



>
> Another way to think of this online forum is like a meetup. We're proposing
> to do a couple of things to be as inclusive as possible -- one is to record
> the presentations so that everyone can see them on their own schedule. The
> other is to refrain from any official decision making at this event. This
> is only intended to facilitate information exchange.
>
> Adam
>
>
>
> On Fri, Feb 1, 2013 at 10:04 AM, Aaron Cordova <aaron@cordovas.org> wrote:
>
> > Benson,
> >
> > Just to be clear (I had to re-read your email a few times to understand)
> > you're saying a real-time online discussion such as Adam is proposing has
> > the potential to exclude some members of the dev community and that we
> > should be sure to stick to things like this email discussion to avoid
> those
> > problems?
> >
> >
> > Thanks,
> >
> > Aaron
> >
> >
> > On Feb 1, 2013, at 2:36 AM, Benson Margulies <bimargulies@gmail.com>
> > wrote:
> >
> > > I want to caution everyone that this process skates close to an edge
> > > of an Apache invariant. An online forum has the potential to exclude
> > > people in far-away time zones or with other constraints. At Apache, we
> > > try to maximize the use of email to avoid this problem.
> > >
> > > Nothing here is an absolute -- I'm not trying to torpedo this plan
> > altogether.
> > >
> > > Nothing, that is, except except that _decisions_ must be made on the
> > > mailing list afterwards.
> > >
> > > If anyone in the dev community feels excluded by this prospect, I
> > > would encourage you to speak up now, so that the planners can make
> > > adjustments to minimize that.
> > >
> > >
> > > On Thu, Jan 31, 2013 at 10:10 PM, Billie Rinaldi
> > > <billie.rinaldi@gmail.com> wrote:
> > >> On Sun, Jan 27, 2013 at 12:43 PM, Eric Newton <eric.newton@gmail.com>
> > wrote:
> > >>
> > >>> What is CAS?
> > >>>
> > >>>   - Switch to Curator.
> > >>>   - Monitoring.  I'm hoping this will just be integration with an
> > existing
> > >>>   tool.
> > >>>   - Namespaces.
> > >>>   - A simple query language.  Perhaps there's something we can
> > collaborate
> > >>>   with some of the other NoSQL folks.
> > >>>   - Update the wiki search example.
> > >>>   - Automatic tablet merge.
> > >>>   - Scalable NN
> > >>>
> > >>
> > >> Is scalable NN == ACCUMULO-722?  I'd be excited about that for 1.6.
> > >>
> > >> Billie
> > >>
> > >>
> > >>
> > >>>
> > >>> Some of these don't need design documents, but some discussion of
> > >>> requirements would be nice.
> > >>>
> > >>> -Eric
> > >>>
> > >>>
> > >>>
> > >>> On Sun, Jan 27, 2013 at 12:26 PM, Keith Turner <keith@deenlo.com>
> > wrote:
> > >>>
> > >>>> This will be very useful.
> > >>>>
> > >>>> Some new features I am thinking about for 1.6 are replication,
CAS,
> > >>>> and Percolator.  I would like to put together a bit of an initial
> > >>>> design document for each of these.  I'm thinking that a follow
up
> > >>>> online deep dive on the design of each large new 1.6 feature would
> > >>>> also be very useful.
> > >>>>
> > >>>> In the coming week I plan to spend most of my time testing,
> > >>>> documenting, fixing bugs, and polishing 1.5.0.  I do not think
this
> > >>>> would leave much time to work on 1.6.  So interleaving design
> > >>>> discussion about new 1.6 features while 1.5 is being polished would
> be
> > >>>> nice.  So once 1.5.0 ships, I would have peer reviewed designs
to
> > >>>> start implementing.
> > >>>>
> > >>>> Keith
> > >>>>
> > >>>> On Sat, Jan 26, 2013 at 8:10 PM, Adam Fuchs <afuchs@apache.org>
> > wrote:
> > >>>>> Folks,
> > >>>>>
> > >>>>> Now that we're past feature freeze for 1.5, I'd like to set
up a
> > >>>> discussion
> > >>>>> of the features that Accumulo developers are interested in
for 1.6
> > and
> > >>>>> beyond. The purpose of this discussion will be to raise awareness
> of
> > >>>>> projects that you think are cool and important, and to rally
the
> > >>>> community.
> > >>>>> As a proposed format, let's plan on a series of 2-5 minute
> > >>> presentations
> > >>>> of
> > >>>>> individual features -- what it is, why it's important, how
should
> we
> > >>>> build
> > >>>>> it, and who needs to help. We'll record the presentations for
> > >>> posterity.
> > >>>>>
> > >>>>> Since the community is now distributed throughout several states,
> > let's
> > >>>> try
> > >>>>> our hand at an online discussion. Depending on participation,
we'll
> > >>> pick
> > >>>> a
> > >>>>> forum that can accomodate everyone. If you're interested in
> > attending,
> > >>>>> please fill out this doodle with what time you would be available:
> > >>>>> http://www.doodle.com/w9zb77ya3ykxr4zv
> > >>>>>
> > >>>>> If you can, please try to fill out the survey by Tuesday afternoon.
> > >>> After
> > >>>>> we get a good feel for times and participation, I'll schedule
an
> > online
> > >>>>> forum and send out a meeting invitation. If you would like
to
> > present a
> > >>>>> feature, send me an email directly at afuchs@apache.org, and
I'll
> > make
> > >>>> sure
> > >>>>> you get time to present it.
> > >>>>>
> > >>>>> I look forward to seeing what everyone has up their sleeves!
> > >>>>>
> > >>>>> Cheers,
> > >>>>> Adam
> > >>>>
> > >>>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message