incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Fluo graduation as TLP
Date Wed, 05 Jul 2017 19:29:56 GMT
On Wed, Jul 5, 2017 at 1:52 PM Dave Fisher <dave2wave@comcast.net> wrote:

> Hi Josh,
>
> I have some questions:
>
> > On Jul 5, 2017, at 10:18 AM, Josh Elser <elserj@apache.org> wrote:
> >
> > As a mentor, I consciously avoided an explicit "+1" until we got some
> IPMC discussion. Let me expand:
> >
> > The current members of Fluo are great, get the Apache Way, and are
> self-sufficient. I have no concerns over them operating as a TLP -- I think
> they are ready. However, they have only added a single committer and I see
> none in the pipeline -- Fluo is defined by the current committers.
>
> (1) Seems to be a niche project as you state below which is just within
> the range of 5 contributors. Am I wrong?
>
> > My hesitation is balancing the Incubators goal of "pushing podlings to
> graduate" and ensuring adequate diversity in the podling. This is
> especially difficult for Fluo as they're "niche on niche" (it's a difficult
> dist-sys problem/software, and not many people use the tech they're
> building on top of given my view of the world).
> >
> > I realize that this discussion could easily spiral out of control,
> turning into some meta-discussion about Incubator goals. I want to avoid
> that.
> >
> > I'm looking for some feelings from other IPMC folks about how to
> approach the Fluo podling given their specific circumstances. If other
> people are also hesitant, I would also be interested in suggestions about
> what we would concretely change (because I don't know what to suggest that
> "fix" the diversity issue for them that isn't changing the core of their
> project). If people aren't worried, I'm happy to give an explicit +1.
>
> (2) Has any consideration been given to becoming a project within
> Accumulo? Or are the goals of Fluo distinct from and not wholly dependent
> on Accumulo?
>
>
I'd like to answer this number (2): This possibility was mentioned by me
after one of our previous status reports as a discussion I'd like to have
on the list. However, I never raised it again on the list to formally
discuss. There's a few potential reasons why I now think that might not
work well, and why I never brought it up again (and probably why nobody
raised it with the Accumulo PMC):

1. The committers do overlap (all but one Fluo PPMC/committer is also an
Accumulo PMC/committer), but Accumulo's PMC is much larger than Fluo's
PPMC. It would not make sense for the Fluo PPMC to grant majority control
to an Accumulo PMC which does not necessarily share the consensus direction
that Fluo is headed. I'm sure Fluo would be happy to incrementally onboard
Accumulo developers as they began participating in Fluo development, but
bringing them in without vetting their merits from the Fluo team's
perspective seems like a bad idea. The Fluo team would probably prefer
decide on the merits of new committers/PMC based on their contributions to
Fluo, rather than automatically inherit any committers from another project.

2. While Fluo is currently implemented on Accumulo, it is not necessarily
the intent for it to remain this way. Under an Accumulo PMC, it is likely
this coupling would solidify, rather than be abstracted. When Fluo was
proposed to the incubator, it was mentioned that we'd be willing to accept
contributions to expand Fluo's feature set so that it works on other
databases. The proposed TLP resolution reflects this willingness to expand
beyond Accumulo by not mentioning Accumulo in its mission statement.

3. Accumulo uses a JIRA-based workflow with pull requests on GitHub and
C-T-R. Fluo is using GitBox with R-T-C. The workflows are very different.
Accumulo's existing bylaws explicitly contradict Fluo's own workflow that
the developers seem comfortable with.

4. Speaking as an Accumulo PMC member, I don't know that I'd want to set a
precedence for accepting Accumulo-related projects as subprojects of
Accumulo, simply because it can be a bit of scope creep for Accumulo. The
Accumulo PMC has already been approached to accept several other extensions
to Accumulo as subprojects from "drive-by" sources who (from appearances)
simply want to offload the maintenance work without community
participation. I can't speak for the rest of the Accumulo PMC, but it seems
preferable to me that the Accumulo PMC protect itself from such DOA code
dumps by leaning towards resisting subprojects (though, having gone through
Incubation can be proof that the code is not going to be DOA). Speaking as
a Fluo PPMC member, I would not want to burden the Accumulo PMC with the
responsibility to regularly evaluate whether to accept bulk code as
subprojects, by opening those flood gates and distracting the PMC from its
primary responsibilities to its existing code.



> (3) Corollary - it seems a large number of Fluo Initial Committers were
> also Accumulo PMC. (I not intentionally rehashing any prior conversation.)
>
> Regards,
> Dave
>
>
> >
> > - Josh
> >
> > On 7/3/17 4:15 PM, John D. Ament wrote:
> >> Hi Christopher,
> >> Thanks for the heads up.  A few nits on my part, but overall I would be
> >> happy to see Fluo graduate.  When reading my notes, please also consult
> the
> >> graduation guide at [1].
> >> - The discussion and vote should have happened on your public dev list,
> not
> >> private.  It's good that at least discussion happened publicly, and the
> >> actual vote isn't required so it's not a big deal.
> >> - I don't see any sign that you added new committers or PPMC members
> since
> >> incubating.  See also [2].  I don't see that as a show stopper, as it
> looks
> >> like a diverse group.
> >> - Of the proposed PMC, how many are actively committing to Fluo?  Was
> there
> >> an ask at any point to see who was still interested?
> >> - Only one mentor voted on the graduation.  Would be great to see if the
> >> other mentors are equally on board.
> >> John
> >> [1]: http://incubator.apache.org/guides/graduation.html#toplevel
> >> [2]: https://whimsy.apache.org/board/minutes/Fluo
> >> On Mon, Jul 3, 2017 at 2:12 PM Christopher <ctubbsii@apache.org> wrote:
> >>> Greetings Incubator,
> >>>
> >>> The Fluo podling has decided to pursue graduation to a TLP. The result
> of
> >>> the internal PPMC vote is at [1] (apologies that it occurred on our
> private
> >>> list instead of on our dev list; the discuss thread [2] which preceded
> it
> >>> did occur on the dev list). Our podling status page has recently been
> >>> updated and can be found here[3].
> >>>
> >>> Below, you can view the proposed TLP resolution which we'd like to
> present
> >>> to the board with the support of the IPMC, after sufficient discussion
> here
> >>> and subsequent IPMC vote.
> >>>
> >>> [1]:
> >>>
> >>>
> https://lists.apache.org/thread.html/04a9de260fcd14b184ae7a8b725e348e13ee4ad10e3057a6a404732c@%3Cprivate.fluo.apache.org%3E
> >>> [2]:
> >>>
> >>>
> https://lists.apache.org/thread.html/3164d77ea18c3e36ce215ab4a07b2cb80cf9c49c2503ef5d1defbdde@%3Cdev.fluo.apache.org%3E
> >>> [3]: https://incubator.apache.org/projects/fluo
> >>>
> >>> **********
> >>> Establish the Apache Fluo Project
> >>>
> >>> WHEREAS, the Board of Directors deems it to be in the best interests of
> >>> the Foundation and consistent with the Foundation's purpose to
> establish
> >>> a Project Management Committee charged with the creation and
> maintenance
> >>> of open-source software, for distribution at no charge to the public,
> >>> related to the storage and incremental processing of large data sets.
> >>>
> >>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> >>> (PMC), to be known as the "Apache Fluo Project", be and hereby is
> >>> established pursuant to Bylaws of the Foundation; and be it further
> >>>
> >>> RESOLVED, that the Apache Fluo Project be and hereby is responsible for
> >>> the creation and maintenance of software related to the storage and
> >>> incremental processing of large data sets; and be it further
> >>>
> >>> RESOLVED, that the office of "Vice President, Apache Fluo" be and
> hereby
> >>> is created, the person holding such office to serve at the direction of
> >>> the Board of Directors as the chair of the Apache Fluo Project, and to
> >>> have primary responsibility for management of the projects within the
> >>> scope of responsibility of the Apache Fluo Project; and be it further
> >>>
> >>> RESOLVED, that the persons listed immediately below be and hereby are
> >>> appointed to serve as the initial members of the Apache Fluo Project:
> >>>
> >>> * Billie Rinaldi <billie@apache.org>
> >>> * Chris McTague <cjmctague@apache.org>
> >>> * Christopher Tubbs <ctubbsii@apache.org>
> >>> * Corey J. Nolet <cjnolet@apache.org>
> >>> * Drew Farris <drew@apache.org>
> >>> * Josh Elser <elserj@apache.org>
> >>> * Keith Turner <kturner@apache.org>
> >>> * Mike Walch <mwalch@apache.org>
> >>>
> >>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Keith Turner be appointed
> >>> to the office of Vice President, Apache Fluo, to serve in accordance
> >>> with and subject to the direction of the Board of Directors and the
> >>> Bylaws of the Foundation until death, resignation, retirement, removal
> >>> or disqualification, or until a successor is appointed; and be it
> >>> further
> >>>
> >>> RESOLVED, that the initial Apache Fluo PMC be and hereby is tasked with
> >>> the creation of a set of bylaws intended to encourage open development
> >>> and increased participation in the Apache Fluo Project; and be it
> >>> further
> >>>
> >>> RESOLVED, that the Apache Fluo Project be and hereby is tasked with the
> >>> migration and rationalization of the Apache Incubator Fluo podling; and
> >>> be it further
> >>>
> >>> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> >>> Fluo podling encumbered upon the Apache Incubator PMC are hereafter
> >>> discharged.
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>

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