You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@yetus.apache.org by Allen Wittenauer <aw...@apache.org> on 2016/03/29 18:25:02 UTC
[DISCUSS] Branch for YETUS-156
Hey gang.
YETUS-156’s purpose is to give Yetus the ability to act as daily/nightly/whateverly build driver for CI systems. This way, Yetus’ reporting could be part of the CI process rather than just digging through mountains of logs looking for errors. The vast majority of changes are purely cosmetic [yay!] but there are quite a few of them to clean up.
Given:
* that we don’t have a branch policy (at least, that I’m aware of….)
* YETUS-156 is working well enough in my tests for people to start playing with it
* YETUS-156 is probably reaching the point where it is ‘too big to review’ (~40k at last rebase)
I think it might be useful to setup a branch for YETUS-156, preferably with a CTRTM (commit then review then merge)-type policy. This would give others a chance to play, break it up into a reviewable state, give me a chance to fix bugs quickly while still providing protection to master if the 0.3.0 train decides to leave before this is ready.
In the mean time, I’ve changed YETUS-156 to be an umbrella, if just for my own sanity.
Any thoughts?
Thanks!
Re: [DISCUSS] Branch for YETUS-156
Posted by Allen Wittenauer <aw...@apache.org>.
Thanks everyone.
I’ve created the YETUS-156 branch and committed a bunch o’ patches to it. It *should* be usable. Build yetus, then use the bin/qbt command against your favorite source tree. Command line options are exactly the same as test-patch (so —plugins=shellcheck is a quick ’n dirty way to try it out). Unbundled personalities will likely need modifications if they override the standard module queuing. (e.g., hadoop, hbase … but they’ve already been modified).
There are likely some bugs still hanging out. Known issues:
* YETUS-336 (duplicate test vote) is _extremely_ pronounced.
* YETUS-354 findbugs always returns a +1, even if problems exist
Let me know how it goes. :)
Thanks!
Re: [DISCUSS] Branch for YETUS-156
Posted by Chris Nauroth <cn...@hortonworks.com>.
Sounds good to me.
--Chris Nauroth
On 3/29/16, 11:06 AM, "Sean Busbey" <bu...@apache.org> wrote:
>Do we already have consensus on what the merge looks like?
>
>Personally, I'm fine treating it like a normal patch. That is, +1
>required from any contributor (N.B. "contributor" rather than
>"committer"). I see no reason to require more work from folks than
>we'd require if Allen wasn't trying to make it easier to see the work
>in pieces.
>
>On Tue, Mar 29, 2016 at 1:04 PM, Sean Busbey <bu...@apache.org> wrote:
>> a branch for commit-then-review-before-merge sounds good to me.
>>
>> On Tue, Mar 29, 2016 at 11:25 AM, Allen Wittenauer <aw...@apache.org>
>>wrote:
>>>
>>> Hey gang.
>>>
>>> YETUS-156¹s purpose is to give Yetus the ability to act as
>>>daily/nightly/whateverly build driver for CI systems. This way, Yetus¹
>>>reporting could be part of the CI process rather than just digging
>>>through mountains of logs looking for errors. The vast majority of
>>>changes are purely cosmetic [yay!] but there are quite a few of them to
>>>clean up.
>>>
>>>
>>> Given:
>>>
>>> * that we don¹t have a branch policy (at least, that
>>>I¹m aware ofŠ.)
>>> * YETUS-156 is working well enough in my tests for
>>>people to start playing with it
>>> * YETUS-156 is probably reaching the point where it is
>>>Œtoo big to review¹ (~40k at last rebase)
>>>
>>> I think it might be useful to setup a branch for YETUS-156,
>>>preferably with a CTRTM (commit then review then merge)-type policy.
>>>This would give others a chance to play, break it up into a reviewable
>>>state, give me a chance to fix bugs quickly while still providing
>>>protection to master if the 0.3.0 train decides to leave before this is
>>>ready.
>>>
>>> In the mean time, I¹ve changed YETUS-156 to be an umbrella, if
>>>just for my own sanity.
>>>
>>> Any thoughts?
>>>
>>> Thanks!
>
Re: [DISCUSS] Branch for YETUS-156
Posted by Sean Busbey <bu...@apache.org>.
Do we already have consensus on what the merge looks like?
Personally, I'm fine treating it like a normal patch. That is, +1
required from any contributor (N.B. "contributor" rather than
"committer"). I see no reason to require more work from folks than
we'd require if Allen wasn't trying to make it easier to see the work
in pieces.
On Tue, Mar 29, 2016 at 1:04 PM, Sean Busbey <bu...@apache.org> wrote:
> a branch for commit-then-review-before-merge sounds good to me.
>
> On Tue, Mar 29, 2016 at 11:25 AM, Allen Wittenauer <aw...@apache.org> wrote:
>>
>> Hey gang.
>>
>> YETUS-156’s purpose is to give Yetus the ability to act as daily/nightly/whateverly build driver for CI systems. This way, Yetus’ reporting could be part of the CI process rather than just digging through mountains of logs looking for errors. The vast majority of changes are purely cosmetic [yay!] but there are quite a few of them to clean up.
>>
>>
>> Given:
>>
>> * that we don’t have a branch policy (at least, that I’m aware of….)
>> * YETUS-156 is working well enough in my tests for people to start playing with it
>> * YETUS-156 is probably reaching the point where it is ‘too big to review’ (~40k at last rebase)
>>
>> I think it might be useful to setup a branch for YETUS-156, preferably with a CTRTM (commit then review then merge)-type policy. This would give others a chance to play, break it up into a reviewable state, give me a chance to fix bugs quickly while still providing protection to master if the 0.3.0 train decides to leave before this is ready.
>>
>> In the mean time, I’ve changed YETUS-156 to be an umbrella, if just for my own sanity.
>>
>> Any thoughts?
>>
>> Thanks!
Re: [DISCUSS] Branch for YETUS-156
Posted by Sean Busbey <bu...@apache.org>.
a branch for commit-then-review-before-merge sounds good to me.
On Tue, Mar 29, 2016 at 11:25 AM, Allen Wittenauer <aw...@apache.org> wrote:
>
> Hey gang.
>
> YETUS-156’s purpose is to give Yetus the ability to act as daily/nightly/whateverly build driver for CI systems. This way, Yetus’ reporting could be part of the CI process rather than just digging through mountains of logs looking for errors. The vast majority of changes are purely cosmetic [yay!] but there are quite a few of them to clean up.
>
>
> Given:
>
> * that we don’t have a branch policy (at least, that I’m aware of….)
> * YETUS-156 is working well enough in my tests for people to start playing with it
> * YETUS-156 is probably reaching the point where it is ‘too big to review’ (~40k at last rebase)
>
> I think it might be useful to setup a branch for YETUS-156, preferably with a CTRTM (commit then review then merge)-type policy. This would give others a chance to play, break it up into a reviewable state, give me a chance to fix bugs quickly while still providing protection to master if the 0.3.0 train decides to leave before this is ready.
>
> In the mean time, I’ve changed YETUS-156 to be an umbrella, if just for my own sanity.
>
> Any thoughts?
>
> Thanks!
Re: [DISCUSS] Branch for YETUS-156
Posted by Andrew Bayer <an...@gmail.com>.
Just make sure you don't turn your build orange!
Since, y'know, rhyming with orange and all.
A.
On Tue, Mar 29, 2016 at 10:07 AM, Chris Nauroth <cn...@hortonworks.com>
wrote:
> Yes, branch away. You can do it today. Keep those broken builds at bay!
>
> I think we need a Dr. Seuss-style children's book about continuous
> integration.
>
> --Chris Nauroth
>
>
>
>
> On 3/29/16, 9:31 AM, "Andrew Bayer" <an...@gmail.com> wrote:
>
> >Branch away, I say. Also I rhyme apparently.
> >
> >A.
> >
> >On Tue, Mar 29, 2016 at 9:25 AM, Allen Wittenauer <aw...@apache.org> wrote:
> >
> >>
> >> Hey gang.
> >>
> >> YETUS-156¹s purpose is to give Yetus the ability to act as
> >> daily/nightly/whateverly build driver for CI systems. This way, Yetus¹
> >> reporting could be part of the CI process rather than just digging
> >>through
> >> mountains of logs looking for errors. The vast majority of changes are
> >> purely cosmetic [yay!] but there are quite a few of them to clean up.
> >>
> >>
> >> Given:
> >>
> >> * that we don¹t have a branch policy (at least, that I¹m
> >> aware ofŠ.)
> >> * YETUS-156 is working well enough in my tests for
> >>people
> >> to start playing with it
> >> * YETUS-156 is probably reaching the point where it is
> >> Œtoo big to review¹ (~40k at last rebase)
> >>
> >> I think it might be useful to setup a branch for YETUS-156,
> >> preferably with a CTRTM (commit then review then merge)-type policy.
> >>This
> >> would give others a chance to play, break it up into a reviewable state,
> >> give me a chance to fix bugs quickly while still providing protection to
> >> master if the 0.3.0 train decides to leave before this is ready.
> >>
> >> In the mean time, I¹ve changed YETUS-156 to be an umbrella, if
> >> just for my own sanity.
> >>
> >> Any thoughts?
> >>
> >> Thanks!
>
>
Re: [DISCUSS] Branch for YETUS-156
Posted by Chris Nauroth <cn...@hortonworks.com>.
Yes, branch away. You can do it today. Keep those broken builds at bay!
I think we need a Dr. Seuss-style children's book about continuous
integration.
--Chris Nauroth
On 3/29/16, 9:31 AM, "Andrew Bayer" <an...@gmail.com> wrote:
>Branch away, I say. Also I rhyme apparently.
>
>A.
>
>On Tue, Mar 29, 2016 at 9:25 AM, Allen Wittenauer <aw...@apache.org> wrote:
>
>>
>> Hey gang.
>>
>> YETUS-156¹s purpose is to give Yetus the ability to act as
>> daily/nightly/whateverly build driver for CI systems. This way, Yetus¹
>> reporting could be part of the CI process rather than just digging
>>through
>> mountains of logs looking for errors. The vast majority of changes are
>> purely cosmetic [yay!] but there are quite a few of them to clean up.
>>
>>
>> Given:
>>
>> * that we don¹t have a branch policy (at least, that I¹m
>> aware ofŠ.)
>> * YETUS-156 is working well enough in my tests for
>>people
>> to start playing with it
>> * YETUS-156 is probably reaching the point where it is
>> Œtoo big to review¹ (~40k at last rebase)
>>
>> I think it might be useful to setup a branch for YETUS-156,
>> preferably with a CTRTM (commit then review then merge)-type policy.
>>This
>> would give others a chance to play, break it up into a reviewable state,
>> give me a chance to fix bugs quickly while still providing protection to
>> master if the 0.3.0 train decides to leave before this is ready.
>>
>> In the mean time, I¹ve changed YETUS-156 to be an umbrella, if
>> just for my own sanity.
>>
>> Any thoughts?
>>
>> Thanks!
Re: [DISCUSS] Branch for YETUS-156
Posted by Andrew Bayer <an...@gmail.com>.
Branch away, I say. Also I rhyme apparently.
A.
On Tue, Mar 29, 2016 at 9:25 AM, Allen Wittenauer <aw...@apache.org> wrote:
>
> Hey gang.
>
> YETUS-156’s purpose is to give Yetus the ability to act as
> daily/nightly/whateverly build driver for CI systems. This way, Yetus’
> reporting could be part of the CI process rather than just digging through
> mountains of logs looking for errors. The vast majority of changes are
> purely cosmetic [yay!] but there are quite a few of them to clean up.
>
>
> Given:
>
> * that we don’t have a branch policy (at least, that I’m
> aware of….)
> * YETUS-156 is working well enough in my tests for people
> to start playing with it
> * YETUS-156 is probably reaching the point where it is
> ‘too big to review’ (~40k at last rebase)
>
> I think it might be useful to setup a branch for YETUS-156,
> preferably with a CTRTM (commit then review then merge)-type policy. This
> would give others a chance to play, break it up into a reviewable state,
> give me a chance to fix bugs quickly while still providing protection to
> master if the 0.3.0 train decides to leave before this is ready.
>
> In the mean time, I’ve changed YETUS-156 to be an umbrella, if
> just for my own sanity.
>
> Any thoughts?
>
> Thanks!