You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Roman Shaposhnik <rv...@apache.org> on 2011/09/26 18:08:06 UTC
Branching strategy for Bigtop
Now that the work on incroparating the upcoming Hadoop 0.22 and
Hadoop 0.23 releases into Bigtop has started I've got a question
on what makes the most sense from a branching strategy point
of view. For example, it is pretty clear to me that the work
for 0.23 belongs in a separate branch in Bigtop. After all,
that code will be used no sooner than Bigtop 0.3.0.
By that same logic one could say that the work on 0.22 also belongs
to a dediacted branch. I'm cool with that, but then I'm not quite
sure what status will trunk have.
IOW, what is our policy to trunk commits? Do we only commit things
into the trunk that can rely on properly released apache projects,
or will it make sense for us to be a tad more aggressive and commit
things that we *hope* will make it to the next release (0.2.0 in this
particular case)?
Thoughts?
Thanks,
Roman.
Re: Branching strategy for Bigtop
Posted by Roman Shaposhnik <rv...@apache.org>.
Ok. Sounds good. I'll push the following branches today:
hadoop-0.22
hadoop-0.23
Thanks,
Roman.
On Tue, Sep 27, 2011 at 10:12 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Roman,
>
> I think the branching strategy should be the same as we imagined/used when you
> and I started working on the BigTop's foundation - iTest framework and stack
> concept.
>
> Here's what it was IIRC (please correct me if I am missing something);
> - whenever you need to work on a specific stack release (say 0.22 based
> Hadoop stack) you branch to reflect whatever specific modifications need
> to be put in there
> - Trunk should be used for development of the framework itself, thus it will
> be used for current rapid development and might be roughly aligned
> with components' trunks as well (or the latest in-release versions of the
> components).
> - branches can be cut from any point of the trunk (or perhaps other
> branches) depending on the need
>
> Hope it still makes sense as it used to last year ;)
> Cos
>
> On Mon, Sep 26, 2011 at 09:08AM, Roman Shaposhnik wrote:
>> Now that the work on incroparating the upcoming Hadoop 0.22 and
>> Hadoop 0.23 releases into Bigtop has started I've got a question
>> on what makes the most sense from a branching strategy point
>> of view. For example, it is pretty clear to me that the work
>> for 0.23 belongs in a separate branch in Bigtop. After all,
>> that code will be used no sooner than Bigtop 0.3.0.
>>
>> By that same logic one could say that the work on 0.22 also belongs
>> to a dediacted branch. I'm cool with that, but then I'm not quite
>> sure what status will trunk have.
>>
>> IOW, what is our policy to trunk commits? Do we only commit things
>> into the trunk that can rely on properly released apache projects,
>> or will it make sense for us to be a tad more aggressive and commit
>> things that we *hope* will make it to the next release (0.2.0 in this
>> particular case)?
>>
>> Thoughts?
>>
>> Thanks,
>> Roman.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iF4EAREIAAYFAk6CrJ8ACgkQenyFlstYjhIiwQD+MvTN5nMS2ZN74d5B4vlyb4MZ
> ZmUXlGAugANtSjRi5qgA/2dJDfwBS9/6KlHrOCKk+PNx2HP0WhbFIG/RJ6jzkjQq
> =+sji
> -----END PGP SIGNATURE-----
>
>
Re: Branching strategy for Bigtop
Posted by Konstantin Boudnik <co...@apache.org>.
Roman,
I think the branching strategy should be the same as we imagined/used when you
and I started working on the BigTop's foundation - iTest framework and stack
concept.
Here's what it was IIRC (please correct me if I am missing something);
- whenever you need to work on a specific stack release (say 0.22 based
Hadoop stack) you branch to reflect whatever specific modifications need
to be put in there
- Trunk should be used for development of the framework itself, thus it will
be used for current rapid development and might be roughly aligned
with components' trunks as well (or the latest in-release versions of the
components).
- branches can be cut from any point of the trunk (or perhaps other
branches) depending on the need
Hope it still makes sense as it used to last year ;)
Cos
On Mon, Sep 26, 2011 at 09:08AM, Roman Shaposhnik wrote:
> Now that the work on incroparating the upcoming Hadoop 0.22 and
> Hadoop 0.23 releases into Bigtop has started I've got a question
> on what makes the most sense from a branching strategy point
> of view. For example, it is pretty clear to me that the work
> for 0.23 belongs in a separate branch in Bigtop. After all,
> that code will be used no sooner than Bigtop 0.3.0.
>
> By that same logic one could say that the work on 0.22 also belongs
> to a dediacted branch. I'm cool with that, but then I'm not quite
> sure what status will trunk have.
>
> IOW, what is our policy to trunk commits? Do we only commit things
> into the trunk that can rely on properly released apache projects,
> or will it make sense for us to be a tad more aggressive and commit
> things that we *hope* will make it to the next release (0.2.0 in this
> particular case)?
>
> Thoughts?
>
> Thanks,
> Roman.
Re: Branching strategy for Bigtop
Posted by Bruno Mahé <bm...@apache.org>.
On 09/27/2011 02:51 PM, Bruno Mahé wrote:
> On 09/26/2011 09:08 AM, Roman Shaposhnik wrote:
>> Now that the work on incroparating the upcoming Hadoop 0.22 and
>> Hadoop 0.23 releases into Bigtop has started I've got a question
>> on what makes the most sense from a branching strategy point
>> of view. For example, it is pretty clear to me that the work
>> for 0.23 belongs in a separate branch in Bigtop. After all,
>> that code will be used no sooner than Bigtop 0.3.0.
>>
>> By that same logic one could say that the work on 0.22 also belongs
>> to a dediacted branch. I'm cool with that, but then I'm not quite
>> sure what status will trunk have.
>>
>> IOW, what is our policy to trunk commits? Do we only commit things
>> into the trunk that can rely on properly released apache projects,
>> or will it make sense for us to be a tad more aggressive and commit
>> things that we *hope* will make it to the next release (0.2.0 in this
>> particular case)?
>>
>> Thoughts?
>>
>> Thanks,
>> Roman.
> My take on it is probably simple:
> * trunk should be in a releasable state
> * If there is some work which will break trunk or make it stable.
> Provided it is a finite amount of work with a known timeline for
> stabilization, I am ok to put it in trunk with optionally making a
> release just before introducing these changes
> * If there are more unknowns to the work, a branch would be more appropriate
>
> In this case, if we have some guarantees regarding hadoop-0.22 and the
> associated integration work, I would be ok for using trunk. But I would
> really prefer to get a release of bigtop out before that.
> Trunk has had a lot of improvements since 0.0.1 and we should make a
> release for hadoop 0.20.2 before jumping to the next version of hadoop.
>
> Thanks,
> Bruno
Second bullet should be:
* If there is some work which will break trunk or make it UNstable.
Provided it is a finite amount of work with a known timeline for
stabilization, I am ok to put it in trunk with optionally making a
release just before introducing these changes
Re: Branching strategy for Bigtop
Posted by Bruno Mahé <bm...@apache.org>.
On 09/26/2011 09:08 AM, Roman Shaposhnik wrote:
> Now that the work on incroparating the upcoming Hadoop 0.22 and
> Hadoop 0.23 releases into Bigtop has started I've got a question
> on what makes the most sense from a branching strategy point
> of view. For example, it is pretty clear to me that the work
> for 0.23 belongs in a separate branch in Bigtop. After all,
> that code will be used no sooner than Bigtop 0.3.0.
>
> By that same logic one could say that the work on 0.22 also belongs
> to a dediacted branch. I'm cool with that, but then I'm not quite
> sure what status will trunk have.
>
> IOW, what is our policy to trunk commits? Do we only commit things
> into the trunk that can rely on properly released apache projects,
> or will it make sense for us to be a tad more aggressive and commit
> things that we *hope* will make it to the next release (0.2.0 in this
> particular case)?
>
> Thoughts?
>
> Thanks,
> Roman.
My take on it is probably simple:
* trunk should be in a releasable state
* If there is some work which will break trunk or make it stable.
Provided it is a finite amount of work with a known timeline for
stabilization, I am ok to put it in trunk with optionally making a
release just before introducing these changes
* If there are more unknowns to the work, a branch would be more appropriate
In this case, if we have some guarantees regarding hadoop-0.22 and the
associated integration work, I would be ok for using trunk. But I would
really prefer to get a release of bigtop out before that.
Trunk has had a lot of improvements since 0.0.1 and we should make a
release for hadoop 0.20.2 before jumping to the next version of hadoop.
Thanks,
Bruno