asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: Podling request: Gerrit
Date Thu, 16 Jul 2015 22:08:06 GMT
Sounds like a plan.  :-)  (Moved this reply over.)

On 7/15/15 5:37 PM, Mattmann, Chris A (3980) wrote:
> Hi Till,
> We should probably move this discussion on to the
> list.
> In short, we shouldn’t have situations in which there are contributors
> who contributions are “shepherded in” by Apache AsterixDB Incubating
> PPMC members whose contributions have an indirect middle man at
> UCI. All development on ASF projects must happen at the ASF.
> We went to great lengths to get the Github workflow integrated into
> our mailing lists for provenance and for foundational tracking
> perspective and ultimately so that we can tell people who use Apache
> software that it’s from a plan and provenance they can trust. Infra
> did a lot of work to make sure contributions have at least an email
> address that flows through to the mailing list.
> Here in the Gerrit situation, it could be similar to Github I suppose
> if we make sure all communication from that Gerrit instance is
> mirror’ed to the list (dev@, or some similar list, probably issues@,
> or something that folks can choose to subscribe to).
> Ideally we need ICLAs on file for anything bigger than smallish
> contributions that have clear mailing list provenance. So, one thing
> you guys are doing is potentially circumventing that review from
> an ASF perspective without this mailing list mirror’ing at the very
> least.
> If ASF infra is willing to throw up a Gerrit instance, that’s the
> most ideal situation. If they are not there is precedence for what
> you guys are doing ( e.g., with Github; and also with build farm
> machines, e.g., such as those contributed by Y! initially when
> Hadoop started, etc.) But this is our core product; code, and it’s
> not something to be taken lightly especially in light of things
> “not happening at the ASF” and for provenance purposes. It’s nice
> that this is going on at UCI, and we appreciate their use of
> resources, however, ASF projects develop and “occur” at the ASF.
> Period.
> Here are the immediate actions:
> 1. Mirror all UCI Gerrit to Apache AsterixDB mailing list (discussed
> in dev@asterixdb.i.a.o and agreed upon by the PPMC within 24-48
> hours) 2. Work with ASF infra (David Nalley is the VP of infra, so
> you have his attention here) to see if they are willing to run a
> Gerrit instance. It’s my understanding David, that the AsterixDB
> folks have a few lingering issues here where they have not heard
> back so if you could reply on those I’d appreciate it.  3. Contributions
> from non AsterixDB PPMC members need to be recognized as such as
> we should be looking to have a discussion about who should be added
> to the PPMC based on the work that’s been going on.
> OK, that sound like a plan? This discussion should move to
> dev@asterixdb.i.a.o if there is nothing more here. This is a community
> and teaching issue that doesn’t need to be on general@.
> Cheers,
> Chris
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email:
> WWW:
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> -----Original Message-----
> From: Till Westmann <>
> Reply-To: "" <>
> Date: Wednesday, July 15, 2015 at 4:18 PM
> To: "" <>
> Subject: Re: Podling request: Gerrit
>>> On Jul 16, 2015, at 12:25 AM, David Nalley <> wrote:
>>> On Wed, Jul 15, 2015 at 5:48 PM, Mattmann, Chris A (3980)
>>> <> wrote:
>>>> Hi Folks,
>>>> Can someone clarify in simple terms what the issue is here?
>>> There's a few issues Chris:
>> Let me try to describe this in terms how most members of the AsterixDB
>> community probably see it.
>>> 1. Contributions are being submitted, discussed, and accepted
>>> externally. No record of the submission, discussion, or acceptance is
>>> currently maintained at the ASF.
>> AsterixDB uses a Gerrit instance hosted at UCI as a code review tool
>> before submitting to the master branch.
>> Discussions on modifications are indeed happening in Gerrit and are
>> currently not forwarded to the ASF mailing lists, but forwarding those
>> discussions should be possible.
>> After discussion, review, and acceptance in the review tool, an AsterixDB
>> committer manually commits the reviewed modification to the master branch
>> in the ASF repository.
>> If the original author of the modification of the code was an AsterixDB
>> committer, the commit should be done by the original author.
>> If the original author was another contributor, the commit should be done
>> by the AsterixDB committer who reviewed and validated the modification.
>>> 2. As in 1) contributions are being accepted externally, and then
>>> synced, to the ASF repo, essentially making it the mirror, rather than
>>> the required canonical copy.
>> Contributions are accepted by an AsterixDB committer on a tool that is
>> not hosted by the ASF.
>> It is not clear why that makes the acceptance external to the project or
>> the ASF.
>> After acceptance, an AsterixDB committer commits the modifications to the
>> ASF repo.
>> The master branch of the ASF repository is considered to be the source of
>> truth and the basis for releases.
>> It is not obvious, why the fact that the modifications were reviewed in
>> Gerrit before being committed to the ASF repo would make the ASF repo a
>> “non-canonical” copy.
>> Till
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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