[
https://issues.apache.org/jira/browse/BIGTOP-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051852#comment-14051852
]
Mark Grover commented on BIGTOP-1363:
-------------------------------------
Big +1 to what Sean said. I don't think individual project release managers
want to release busted releases, If we were to do a better job of helping them
stabilize their releases (and Sean's suggestion opens that avenue), I think we
would see a big reduction in the number of cases we get bitten by busted
releases.
I think while you still have a valid point about Bigtop managing patches, but
IMO that comes at a good chunk of cost and complexity. Integrating directly
with source code repositories of upstream projects may give us a much better
bang for the buck.
> (Discussion) Bigtop may manage apache patches
> ---------------------------------------------
>
> Key: BIGTOP-1363
> URL: https://issues.apache.org/jira/browse/BIGTOP-1363
> Project: Bigtop
> Issue Type: Improvement
> Components: Build
> Reporter: Guo Ruijing
>
> Bigtop may manage apache patches.
> Motivation 1: component build fails due to some apache patches. bigtop don't
> need to wait for component rebase to workaround component build failure.
> Example 1) Hadoop build fails in bigtop-0.6.0/bigtop-0.7.0 build fails due to
> HADOOP-10110.patch missing.
> Example 2) flume 1.4.0 build fails due to Flume-2172
> Motivation 2: third party can use bigtop to manage apache or vendor patches
> (Not bigtop goal, but if more people use bigtop to do distribution, bigtop is
> more stable)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
