>> >> > from branch-2. If a contributor wants to see their fix
> > reach
> > > to
> > > > >> users
> > > > >> >>on
> > > > >> >> a
> > > > >> >> > stable line quickly they w
gt; stable line quickly they would have to have a fix on
> > branch-2.
> > > >> Also, a
> > > >> >> > release manager can pick whatever fixes she wants, so even
> if
> > > >> >>contributor
> > > >> >&
>>contributor
> > >> >> > doesn't commit it on branch-2, a release manger who wants to
> > do a
> > >> >>release
> > >> >> > containing a set of fixes thats always possible.
> > >
> of
> >> >> >> 2.x
> >> >> >> > to be backward compatible. At the same time whenever they
> >> decide to
> >> >> >> upgrade
> >> >> >> > they only need to test their application once against 3.x a
>> > focussed bug fix backport should be possible.
>> >> >
>> >> >
>> >> >- *Removal of MR2 on the master branch*.
>> >> > This is something I personally would like to see. But exact
>> timing of
>
nally would like to see. But exact
> timing of
> >>it
> >> > will be decided by community. I am certainly not saying that as
> soon
> >>as
> >> > branch-2 is created, lets remove MR2 on master.
> >> >
> >> >
rtainly not saying that as soon
>>as
>> > branch-2 is created, lets remove MR2 on master.
>> >
>> > I would also say that in the end ASF is volunteer organization, we
>>cant
>> > force people to adopt one branch or another. Its
gt;as
>> > branch-2 is created, lets remove MR2 on master.
>> >
>> > I would also say that in the end ASF is volunteer organization, we
>>cant
>> > force people to adopt one branch or another. Its upto the contributors
>> what
>> > jiras they
on as
> > branch-2 is created, lets remove MR2 on master.
> >
> > I would also say that in the end ASF is volunteer organization, we cant
> > force people to adopt one branch or another. Its upto the contributors
> what
> > jiras they work on and when and wher
so say that in the end ASF is volunteer organization, we cant
> force people to adopt one branch or another. Its upto the contributors what
> jiras they work on and when and where they commit it.
> By not creating a branch-2 only thing we can guarantee is that rate of
> development on m
jiras they work on and when and where they commit it.
By not creating a branch-2 only thing we can guarantee is that rate of
development on master to remain slow because we don't want to start doing
backward incompatible changes without explicitly acknowledging that.
Thanks,
Ashutosh
On Thu,
gt; >
> > >> > Hive project has come a long way. With wide-spread adoption also
> comes
> > >> > expectations. Expectation of being backward compatible and not
> > breaking
> > >> > things. However that doesn't come free of cost and resu
ree of cost and results in lot of
> >> legacy
> >> > code which can't be refactored without fear of breaking things. As a
> >> result
> >> > project has accumulated lot of debt over time. At the same time there
> >> are
> >> > a
We may want to drop
> >some of those.
> >
> >In order to move forward and shed that debt we may need a major version
> >release which allows us to make backward incompatible changes and drop
> >rarely used features. At the same time there are lots of users which are
&g
x27;t be refactored without fear of breaking things. As a
> result
> project has accumulated lot of debt over time. At the same time there
> are
> also lot of features which have seen little uptake. We may want to drop
> some of those.
>
> In order to move forwa
7;t be refactored without fear of breaking things. As a
> > >result
> > >project has accumulated lot of debt over time. At the same time there
> are
> > >also lot of features which have seen little uptake. We may want to drop
> > >some of those.
> > >
t; > code which can't be refactored without fear of breaking things. As a
>> result
>> > project has accumulated lot of debt over time. At the same time there
>> are
>> > also lot of features which have seen little uptake. We may want to drop
>> > some
to drop
> > some of those.
> >
> > In order to move forward and shed that debt we may need a major version
> > release which allows us to make backward incompatible changes and drop
> > rarely used features. At the same time there are lots of users which are
> &
f breaking things. As a
result
project has accumulated lot of debt over time. At the same time there are
also lot of features which have seen little uptake. We may want to drop
some of those.
In order to move forward and shed that debt we may need a major version
release which allows us to make
At the same time there are
> also lot of features which have seen little uptake. We may want to drop
> some of those.
>
> In order to move forward and shed that debt we may need a major version
> release which allows us to make backward incompatible changes and drop
> rarely used f
t of features which have seen little uptake. We may want to drop
> >some of those.
> >
> >In order to move forward and shed that debt we may need a major version
> >release which allows us to make backward incompatible changes and drop
> >rarely used features. At the
eatures which have seen little uptake. We may want to drop
>some of those.
>
>In order to move forward and shed that debt we may need a major version
>release which allows us to make backward incompatible changes and drop
>rarely used features. At the same time there are lots of use
ings. As a result
project has accumulated lot of debt over time. At the same time there are
also lot of features which have seen little uptake. We may want to drop
some of those.
In order to move forward and shed that debt we may need a major version
release which allows us to make backward in
23 matches
Mail list logo
