Oh, typo, 'the make_rc.sh can do everything for you'

张铎(Duo Zhang) <palomino...@gmail.com> 于2018年11月9日周五 上午10:09写道:

> I think for the 2.x release the problem is that we are still busy on
> making the code stable, or speak more clearly, to make the procedure v2
> framework stable... And another big problem is lacking of HBCK2 support.
> These things are all big issues which prevent people to upgrade to 2.x.
>
> Once these things are done, I think a monthly release will not be a big
> problem to the RMs. Just simply run an ITBLL(for now it is not easy to get
> a successful run and then we need to find out why...), and then the
> make_rc.sh can not everything for you...
>
> Sean Busbey <bus...@apache.org> 于2018年11月9日周五 上午9:45写道:
>
>> I think it just shifts the RM burden, no? Like instead of watching e.g.
>> branch-2.2 I instead need to watch branch-2.
>>
>> On Thu, Nov 8, 2018, 17:28 Josh Elser <els...@apache.org wrote:
>>
>> > I think what I'd be concerned about WRT time-based releases is the
>> > burden on RM to keep the branch in a good state. Perhaps we need to not
>> > push that onto an RM and do better about sharing that load (looking in
>> > the mirror).
>> >
>> > However, I do like time-based releases as a means to avoid "hurt
>> > feelings" (e.g. the personal ties of a developer to a feature. "The
>> > release goes out on zzzz/yy/xx, this feature is not yet ready, can go
>> > out one month later.." etc)
>> >
>> > On 11/7/18 2:31 PM, Sean Busbey wrote:
>> > > Hi folks!
>> > >
>> > > Some time ago we talked about trying to get back on track for a more
>> > > regular cadence of minor releases rather than maintenance releases
>> > > (like how we did back pre-1.0). That never quite worked out for the
>> > > HBase 1.y line, but is still something we could make happen for HBase
>> > > 2.
>> > >
>> > > We're coming up on 4 months since the 2.1 release line started. ATM
>> > > there are 63 issues in JIRA that claim to be in 2.2.0 and not in any
>> > > 2.1.z version[1].
>> > >
>> > > The main argument against starting to do a 2.2.0 release is that
>> > > nothing springs out of that list as a "feature" that would entice
>> > > users to upgrade. Waiting for these kinds of selling points to drive a
>> > > release is commonly referred to as "feature based releases." I think
>> > > it would be fair to characterize the HBase 2.0 release as feature
>> > > based centered on AMv2.
>> > >
>> > > An alternative to feature based releases is date based releases where
>> > > we decide that e.g. we'll have a minor release each month regardless
>> > > of how much is included in it. This is sometimes also called "train
>> > > releases" as an analogy to how trains leave a station on a set
>> > > schedule without regard to which individual passengers are ready. Just
>> > > as you'd catch the next scheduled train if you miss-timed your
>> > > arrival, fixes or features that aren't ready just go in the next
>> > > regular release.
>> > >
>> > > Personally, I really like the idea of doing date based releases for
>> > > minor releases with maintenance releases essentially only happening on
>> > > whatever our "stable" designator points at. It would mean those who
>> > > don't want the risk and benefits of our current release-ready work
>> > > could stay on a defined path while we could move away from maintaining
>> > > a ton of branches, some of which don't even see releases (currently ~3
>> > > that are > 3 months since a release). If some folks had a specific
>> > > need for a different minor release line and were willing to do the
>> > > backport and RM work for that line, they'd of course be free to do so.
>> > >
>> > > I know there are some current unknowns around 2.2 specifically. I
>> > > think stack mentioned to me that there's an upgrade consideration that
>> > > we need to hammer out since I don't see anything specific to 2.2 in
>> > > the "Upgrade Paths" section of the ref guide right now. While I am
>> > > interested in getting 2.2 going specifically, I'd like to make sure we
>> > > address the general topic of regularly getting new minor releases out.
>> > > If we already had an expectation that there'd be a minor release every
>> > > e.g. month or 2 months then I expect whatever upgrade issue would have
>> > > been addressed as a part of the change that caused it going in.
>> > >
>> > > What do folks think?
>> > >
>> > > [1]:
>> > > https://s.apache.org/AAma
>> > >
>> >
>>
>

Reply via email to