incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amol Kekre <>
Subject Re: [DISCUSS] Apex Incubation Proposal
Date Tue, 11 Aug 2015 05:49:24 GMT
Malhar has much faster release frequency. We have so far managed the
discrepancy in release frequency with two repos. Malhar depends on a stable
Apex branch. Operationally we found two repos to be very efficient. Same
folks worked on both, so the coding roles are not separated. There may be
other ways of resolving this, but as Ted say it has become a matter of de

We are proposing that we be approved to evaluate two repos during
incubation. If it does not work well, the community can always evaluate
single repo.


On Mon, Aug 10, 2015 at 9:57 PM, Ted Dunning <> wrote:

> On Mon, Aug 10, 2015 at 8:04 PM, Roman Shaposhnik <>
> wrote:
> > > The primary difference between these is that Malhar is expected to be
> > > released much more frequently than Apex as new functions are added.
> > Also,
> > > as a platform, there is much more burden on Apex to be stable, thus
> > > decreasing the desirable release frequency.  Over time, it is likely
> that
> > > newcomers are more likely to find it easy to contribute on the Malhar
> > side
> > > initially, but the existing community is fine with keeping the
> committer
> > > pool uniform.
> >
> > Ok, that makes sense, but it also leads to the next question. With such
> > tight integration why ask for different JIRAs for the two projects and
> two
> > different repos? Keeping with your HDFS/YARN analogy, say what you
> > will, but part of the reason Hadoop was able to innovate so quickly
> > was that those were part of the same project.
> I argued against the dual repository, but the project contributors
> apparently had a strong opinion about that.
> This will have nothing to do with whether the two systems are part of the
> same project. They will still be synchronized.
> In the end, it seemed a matter of de gustibus.

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