[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Tom Rini]

Hey all,

Since Jagan promise a v2 SPI PR for some build fixes that we should have
in the release and I believe didn't get them out before the end of his
day, I'm letting everyone know now to expect the release tomorrow
instead, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181112/172205f9/attachment.sig>

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Marek Vasut]

On 11/12/2018 10:40 PM, Tom Rini wrote:
> Hey all,
> 
> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> in the release and I believe didn't get them out before the end of his
> day, I'm letting everyone know now to expect the release tomorrow
> instead, thanks!

Will anyone have any chance to test those fixes to verify they didn't
break anything ?

I believe this is yet another manifestation of the problems of the 2
month release cycle, which I think is too short and stressful.

-- 
Best regards,
Marek Vasut

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Tom Rini]

On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
> On 11/12/2018 10:40 PM, Tom Rini wrote:
> > Hey all,
> > 
> > Since Jagan promise a v2 SPI PR for some build fixes that we should have
> > in the release and I believe didn't get them out before the end of his
> > day, I'm letting everyone know now to expect the release tomorrow
> > instead, thanks!
> 
> Will anyone have any chance to test those fixes to verify they didn't
> break anything ?

Since they're obvious enough by inspection, I'm not worried about it.

> I believe this is yet another manifestation of the problems of the 2
> month release cycle, which I think is too short and stressful.

And I believe that's a red herring.  All the same I am still considering
changes.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181112/15ba44f1/attachment.sig>

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Marek Vasut]

On 11/12/2018 11:25 PM, Tom Rini wrote:
> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
>> On 11/12/2018 10:40 PM, Tom Rini wrote:
>>> Hey all,
>>>
>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>> in the release and I believe didn't get them out before the end of his
>>> day, I'm letting everyone know now to expect the release tomorrow
>>> instead, thanks!
>>
>> Will anyone have any chance to test those fixes to verify they didn't
>> break anything ?
> 
> Since they're obvious enough by inspection, I'm not worried about it.

Which patches are those ?

>> I believe this is yet another manifestation of the problems of the 2
>> month release cycle, which I think is too short and stressful.
> 
> And I believe that's a red herring.  All the same I am still considering
> changes.

I'd really like to know how do other maintainers feel about this 2 month
release cycle vs. for example 3 month like Linux does. I think the later
is about right, 2 months is too short.

-- 
Best regards,
Marek Vasut

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Tom Rini]

On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:
> On 11/12/2018 11:25 PM, Tom Rini wrote:
> > On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
> >> On 11/12/2018 10:40 PM, Tom Rini wrote:
> >>> Hey all,
> >>>
> >>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> >>> in the release and I believe didn't get them out before the end of his
> >>> day, I'm letting everyone know now to expect the release tomorrow
> >>> instead, thanks!
> >>
> >> Will anyone have any chance to test those fixes to verify they didn't
> >> break anything ?
> > 
> > Since they're obvious enough by inspection, I'm not worried about it.
> 
> Which patches are those ?

The ones in question?

> >> I believe this is yet another manifestation of the problems of the 2
> >> month release cycle, which I think is too short and stressful.
> > 
> > And I believe that's a red herring.  All the same I am still considering
> > changes.
> 
> I'd really like to know how do other maintainers feel about this 2 month
> release cycle vs. for example 3 month like Linux does. I think the later
> is about right, 2 months is too short.

Yes, I've asked before and there's a few people in the same camp as you,
and there's a few people who like 2 months, and there's a large number
of no strong opinions.  That's why I'm still thinking about changing
things again.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181112/9a89dd0d/attachment.sig>

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Marek Vasut]

On 11/13/2018 02:12 AM, Tom Rini wrote:
> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:
>> On 11/12/2018 11:25 PM, Tom Rini wrote:
>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
>>>> On 11/12/2018 10:40 PM, Tom Rini wrote:
>>>>> Hey all,
>>>>>
>>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>>>> in the release and I believe didn't get them out before the end of his
>>>>> day, I'm letting everyone know now to expect the release tomorrow
>>>>> instead, thanks!
>>>>
>>>> Will anyone have any chance to test those fixes to verify they didn't
>>>> break anything ?
>>>
>>> Since they're obvious enough by inspection, I'm not worried about it.
>>
>> Which patches are those ?
> 
> The ones in question?

Yes, is there a list ?

>>>> I believe this is yet another manifestation of the problems of the 2
>>>> month release cycle, which I think is too short and stressful.
>>>
>>> And I believe that's a red herring.  All the same I am still considering
>>> changes.
>>
>> I'd really like to know how do other maintainers feel about this 2 month
>> release cycle vs. for example 3 month like Linux does. I think the later
>> is about right, 2 months is too short.
> 
> Yes, I've asked before and there's a few people in the same camp as you,
> and there's a few people who like 2 months, and there's a large number
> of no strong opinions.  That's why I'm still thinking about changing
> things again.

Maybe we need a poll ?

-- 
Best regards,
Marek Vasut

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Miquel Raynal]

Hi Marek,

+Jagan

Marek Vasut <marek.vasut@gmail.com> wrote on Tue, 13 Nov 2018 03:12:49
+0100:

> On 11/13/2018 02:12 AM, Tom Rini wrote:
> > On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:  
> >> On 11/12/2018 11:25 PM, Tom Rini wrote:  
> >>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:  
> >>>> On 11/12/2018 10:40 PM, Tom Rini wrote:  
> >>>>> Hey all,
> >>>>>
> >>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> >>>>> in the release and I believe didn't get them out before the end of his
> >>>>> day, I'm letting everyone know now to expect the release tomorrow
> >>>>> instead, thanks!  
> >>>>
> >>>> Will anyone have any chance to test those fixes to verify they didn't
> >>>> break anything ?  
> >>>
> >>> Since they're obvious enough by inspection, I'm not worried about it.  
> >>
> >> Which patches are those ?  
> > 
> > The ones in question?  
> 
> Yes, is there a list ?

I think this is the branch:
https://github.com/openedev/u-boot-amarula/commits/v2-WIP5

And the successful Travis builds:
https://travis-ci.org/openedev/u-boot-amarula/builds/453885472

> 
> >>>> I believe this is yet another manifestation of the problems of the 2
> >>>> month release cycle, which I think is too short and stressful.  
> >>>
> >>> And I believe that's a red herring.  All the same I am still considering
> >>> changes.  
> >>
> >> I'd really like to know how do other maintainers feel about this 2 month
> >> release cycle vs. for example 3 month like Linux does. I think the later
> >> is about right, 2 months is too short.  
> > 
> > Yes, I've asked before and there's a few people in the same camp as you,
> > and there's a few people who like 2 months, and there's a large number
> > of no strong opinions.  That's why I'm still thinking about changing
> > things again.  
> 
> Maybe we need a poll ?

I do agree on this.


Thanks,
Miquèl

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Marek Vasut]

On 11/13/2018 11:33 AM, Miquel Raynal wrote:
> Hi Marek,
> 
> +Jagan
> 
> Marek Vasut <marek.vasut@gmail.com> wrote on Tue, 13 Nov 2018 03:12:49
> +0100:
> 
>> On 11/13/2018 02:12 AM, Tom Rini wrote:
>>> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:  
>>>> On 11/12/2018 11:25 PM, Tom Rini wrote:  
>>>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:  
>>>>>> On 11/12/2018 10:40 PM, Tom Rini wrote:  
>>>>>>> Hey all,
>>>>>>>
>>>>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>>>>>> in the release and I believe didn't get them out before the end of his
>>>>>>> day, I'm letting everyone know now to expect the release tomorrow
>>>>>>> instead, thanks!  
>>>>>>
>>>>>> Will anyone have any chance to test those fixes to verify they didn't
>>>>>> break anything ?  
>>>>>
>>>>> Since they're obvious enough by inspection, I'm not worried about it.  
>>>>
>>>> Which patches are those ?  
>>>
>>> The ones in question?  
>>
>> Yes, is there a list ?
> 
> I think this is the branch:
> https://github.com/openedev/u-boot-amarula/commits/v2-WIP5

Ugh, patchwork links would be nice.

But for example
https://github.com/openedev/u-boot-amarula/commit/91d8f9979420827942ca1f336df36504bd2c1943

is quite inobvious, and I think buggy ...

 	else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts) != -1))

sizeof(tmp_parts) != -1 will always be true.

> And the successful Travis builds:
> https://travis-ci.org/openedev/u-boot-amarula/builds/453885472
> 
>>
>>>>>> I believe this is yet another manifestation of the problems of the 2
>>>>>> month release cycle, which I think is too short and stressful.  
>>>>>
>>>>> And I believe that's a red herring.  All the same I am still considering
>>>>> changes.  
>>>>
>>>> I'd really like to know how do other maintainers feel about this 2 month
>>>> release cycle vs. for example 3 month like Linux does. I think the later
>>>> is about right, 2 months is too short.  
>>>
>>> Yes, I've asked before and there's a few people in the same camp as you,
>>> and there's a few people who like 2 months, and there's a large number
>>> of no strong opinions.  That's why I'm still thinking about changing
>>> things again.  
>>
>> Maybe we need a poll ?
> 
> I do agree on this.
> 
> 
> Thanks,
> Miquèl
> 


-- 
Best regards,
Marek Vasut

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Boris Brezillon]

On Tue, 13 Nov 2018 11:41:48 +0100
Marek Vasut <marek.vasut@gmail.com> wrote:

> On 11/13/2018 11:33 AM, Miquel Raynal wrote:
> > Hi Marek,
> > 
> > +Jagan
> > 
> > Marek Vasut <marek.vasut@gmail.com> wrote on Tue, 13 Nov 2018 03:12:49
> > +0100:
> >   
> >> On 11/13/2018 02:12 AM, Tom Rini wrote:  
> >>> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:    
> >>>> On 11/12/2018 11:25 PM, Tom Rini wrote:    
> >>>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:    
> >>>>>> On 11/12/2018 10:40 PM, Tom Rini wrote:    
> >>>>>>> Hey all,
> >>>>>>>
> >>>>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> >>>>>>> in the release and I believe didn't get them out before the end of his
> >>>>>>> day, I'm letting everyone know now to expect the release tomorrow
> >>>>>>> instead, thanks!    
> >>>>>>
> >>>>>> Will anyone have any chance to test those fixes to verify they didn't
> >>>>>> break anything ?    
> >>>>>
> >>>>> Since they're obvious enough by inspection, I'm not worried about it.    
> >>>>
> >>>> Which patches are those ?    
> >>>
> >>> The ones in question?    
> >>
> >> Yes, is there a list ?  
> > 
> > I think this is the branch:
> > https://github.com/openedev/u-boot-amarula/commits/v2-WIP5  
> 
> Ugh, patchwork links would be nice.

See here [1].

> 
> But for example
> https://github.com/openedev/u-boot-amarula/commit/91d8f9979420827942ca1f336df36504bd2c1943
> 
> is quite inobvious, and I think buggy ...
> 
>  	else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts) != -1))
> 
> sizeof(tmp_parts) != -1 will always be true.

Indeed, I misplaced the closing parens, should be

	else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts)) !=	-1)

[1]http://patchwork.ozlabs.org/project/uboot/list/?series=75389

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Stefano Babic]

On 13/11/18 01:03, Marek Vasut wrote:
> On 11/12/2018 11:25 PM, Tom Rini wrote:
>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
>>> On 11/12/2018 10:40 PM, Tom Rini wrote:
>>>> Hey all,
>>>>
>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>>> in the release and I believe didn't get them out before the end of his
>>>> day, I'm letting everyone know now to expect the release tomorrow
>>>> instead, thanks!
>>>
>>> Will anyone have any chance to test those fixes to verify they didn't
>>> break anything ?
>>
>> Since they're obvious enough by inspection, I'm not worried about it.
> 
> Which patches are those ?
> 
>>> I believe this is yet another manifestation of the problems of the 2
>>> month release cycle, which I think is too short and stressful.
>>
>> And I believe that's a red herring.  All the same I am still considering
>> changes.
> 
> I'd really like to know how do other maintainers feel about this 2 month
> release cycle vs. for example 3 month like Linux does.

My two cents..

> I think the later
> is about right, 2 months is too short.

+1

I vote for 3 months release cycle, too. If I remember well, we had
already such as a discussion in the past, and at least some of us (I was
one of them) ask to increase the release cycle.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Marek Vasut]

On 11/13/2018 11:54 AM, Boris Brezillon wrote:
> On Tue, 13 Nov 2018 11:41:48 +0100
> Marek Vasut <marek.vasut@gmail.com> wrote:
> 
>> On 11/13/2018 11:33 AM, Miquel Raynal wrote:
>>> Hi Marek,
>>>
>>> +Jagan
>>>
>>> Marek Vasut <marek.vasut@gmail.com> wrote on Tue, 13 Nov 2018 03:12:49
>>> +0100:
>>>   
>>>> On 11/13/2018 02:12 AM, Tom Rini wrote:  
>>>>> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:    
>>>>>> On 11/12/2018 11:25 PM, Tom Rini wrote:    
>>>>>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:    
>>>>>>>> On 11/12/2018 10:40 PM, Tom Rini wrote:    
>>>>>>>>> Hey all,
>>>>>>>>>
>>>>>>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>>>>>>>> in the release and I believe didn't get them out before the end of his
>>>>>>>>> day, I'm letting everyone know now to expect the release tomorrow
>>>>>>>>> instead, thanks!    
>>>>>>>>
>>>>>>>> Will anyone have any chance to test those fixes to verify they didn't
>>>>>>>> break anything ?    
>>>>>>>
>>>>>>> Since they're obvious enough by inspection, I'm not worried about it.    
>>>>>>
>>>>>> Which patches are those ?    
>>>>>
>>>>> The ones in question?    
>>>>
>>>> Yes, is there a list ?  
>>>
>>> I think this is the branch:
>>> https://github.com/openedev/u-boot-amarula/commits/v2-WIP5  
>>
>> Ugh, patchwork links would be nice.
> 
> See here [1].
> 
>>
>> But for example
>> https://github.com/openedev/u-boot-amarula/commit/91d8f9979420827942ca1f336df36504bd2c1943
>>
>> is quite inobvious, and I think buggy ...
>>
>>  	else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts) != -1))
>>
>> sizeof(tmp_parts) != -1 will always be true.
> 
> Indeed, I misplaced the closing parens, should be
> 
> 	else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts)) !=	-1)

And the -1 too, even if you move the parenthesis, according to
include/common.h .

-- 
Best regards,
Marek Vasut

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Jagan Teki]

On Tue, Nov 13, 2018 at 4:33 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>
> On 11/13/2018 11:54 AM, Boris Brezillon wrote:
> > On Tue, 13 Nov 2018 11:41:48 +0100
> > Marek Vasut <marek.vasut@gmail.com> wrote:
> >
> >> On 11/13/2018 11:33 AM, Miquel Raynal wrote:
> >>> Hi Marek,
> >>>
> >>> +Jagan
> >>>
> >>> Marek Vasut <marek.vasut@gmail.com> wrote on Tue, 13 Nov 2018 03:12:49
> >>> +0100:
> >>>
> >>>> On 11/13/2018 02:12 AM, Tom Rini wrote:
> >>>>> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:
> >>>>>> On 11/12/2018 11:25 PM, Tom Rini wrote:
> >>>>>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
> >>>>>>>> On 11/12/2018 10:40 PM, Tom Rini wrote:
> >>>>>>>>> Hey all,
> >>>>>>>>>
> >>>>>>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> >>>>>>>>> in the release and I believe didn't get them out before the end of his
> >>>>>>>>> day, I'm letting everyone know now to expect the release tomorrow
> >>>>>>>>> instead, thanks!
> >>>>>>>>
> >>>>>>>> Will anyone have any chance to test those fixes to verify they didn't
> >>>>>>>> break anything ?
> >>>>>>>
> >>>>>>> Since they're obvious enough by inspection, I'm not worried about it.
> >>>>>>
> >>>>>> Which patches are those ?
> >>>>>
> >>>>> The ones in question?
> >>>>
> >>>> Yes, is there a list ?
> >>>
> >>> I think this is the branch:
> >>> https://github.com/openedev/u-boot-amarula/commits/v2-WIP5
> >>
> >> Ugh, patchwork links would be nice.
> >
> > See here [1].
> >
> >>
> >> But for example
> >> https://github.com/openedev/u-boot-amarula/commit/91d8f9979420827942ca1f336df36504bd2c1943
> >>
> >> is quite inobvious, and I think buggy ...
> >>
> >>      else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts) != -1))
> >>
> >> sizeof(tmp_parts) != -1 will always be true.
> >
> > Indeed, I misplaced the closing parens, should be
> >
> >       else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts)) != -1)
>
> And the -1 too, even if you move the parenthesis, according to
> include/common.h .

Travis-ci build fine for all, can we have a fix for this so-that we
move accordingly. these fixes are important and need to move for the
release.

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Marek Vasut]

On 11/13/2018 12:15 PM, Jagan Teki wrote:
> On Tue, Nov 13, 2018 at 4:33 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>
>> On 11/13/2018 11:54 AM, Boris Brezillon wrote:
>>> On Tue, 13 Nov 2018 11:41:48 +0100
>>> Marek Vasut <marek.vasut@gmail.com> wrote:
>>>
>>>> On 11/13/2018 11:33 AM, Miquel Raynal wrote:
>>>>> Hi Marek,
>>>>>
>>>>> +Jagan
>>>>>
>>>>> Marek Vasut <marek.vasut@gmail.com> wrote on Tue, 13 Nov 2018 03:12:49
>>>>> +0100:
>>>>>
>>>>>> On 11/13/2018 02:12 AM, Tom Rini wrote:
>>>>>>> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:
>>>>>>>> On 11/12/2018 11:25 PM, Tom Rini wrote:
>>>>>>>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
>>>>>>>>>> On 11/12/2018 10:40 PM, Tom Rini wrote:
>>>>>>>>>>> Hey all,
>>>>>>>>>>>
>>>>>>>>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>>>>>>>>>> in the release and I believe didn't get them out before the end of his
>>>>>>>>>>> day, I'm letting everyone know now to expect the release tomorrow
>>>>>>>>>>> instead, thanks!
>>>>>>>>>>
>>>>>>>>>> Will anyone have any chance to test those fixes to verify they didn't
>>>>>>>>>> break anything ?
>>>>>>>>>
>>>>>>>>> Since they're obvious enough by inspection, I'm not worried about it.
>>>>>>>>
>>>>>>>> Which patches are those ?
>>>>>>>
>>>>>>> The ones in question?
>>>>>>
>>>>>> Yes, is there a list ?
>>>>>
>>>>> I think this is the branch:
>>>>> https://github.com/openedev/u-boot-amarula/commits/v2-WIP5
>>>>
>>>> Ugh, patchwork links would be nice.
>>>
>>> See here [1].
>>>
>>>>
>>>> But for example
>>>> https://github.com/openedev/u-boot-amarula/commit/91d8f9979420827942ca1f336df36504bd2c1943
>>>>
>>>> is quite inobvious, and I think buggy ...
>>>>
>>>>      else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts) != -1))
>>>>
>>>> sizeof(tmp_parts) != -1 will always be true.
>>>
>>> Indeed, I misplaced the closing parens, should be
>>>
>>>       else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts)) != -1)
>>
>> And the -1 too, even if you move the parenthesis, according to
>> include/common.h .
> 
> Travis-ci build fine for all, can we have a fix for this so-that we
> move accordingly. these fixes are important and need to move for the
> release.

That patch is buggy and needs to be respun and retested. I don't think
you can push known buggy patch into a release as a fix.

-- 
Best regards,
Marek Vasut

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Jagan Teki]

On Tue, Nov 13, 2018 at 4:53 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>
> On 11/13/2018 12:15 PM, Jagan Teki wrote:
> > On Tue, Nov 13, 2018 at 4:33 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>
> >> On 11/13/2018 11:54 AM, Boris Brezillon wrote:
> >>> On Tue, 13 Nov 2018 11:41:48 +0100
> >>> Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>
> >>>> On 11/13/2018 11:33 AM, Miquel Raynal wrote:
> >>>>> Hi Marek,
> >>>>>
> >>>>> +Jagan
> >>>>>
> >>>>> Marek Vasut <marek.vasut@gmail.com> wrote on Tue, 13 Nov 2018 03:12:49
> >>>>> +0100:
> >>>>>
> >>>>>> On 11/13/2018 02:12 AM, Tom Rini wrote:
> >>>>>>> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:
> >>>>>>>> On 11/12/2018 11:25 PM, Tom Rini wrote:
> >>>>>>>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
> >>>>>>>>>> On 11/12/2018 10:40 PM, Tom Rini wrote:
> >>>>>>>>>>> Hey all,
> >>>>>>>>>>>
> >>>>>>>>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
> >>>>>>>>>>> in the release and I believe didn't get them out before the end of his
> >>>>>>>>>>> day, I'm letting everyone know now to expect the release tomorrow
> >>>>>>>>>>> instead, thanks!
> >>>>>>>>>>
> >>>>>>>>>> Will anyone have any chance to test those fixes to verify they didn't
> >>>>>>>>>> break anything ?
> >>>>>>>>>
> >>>>>>>>> Since they're obvious enough by inspection, I'm not worried about it.
> >>>>>>>>
> >>>>>>>> Which patches are those ?
> >>>>>>>
> >>>>>>> The ones in question?
> >>>>>>
> >>>>>> Yes, is there a list ?
> >>>>>
> >>>>> I think this is the branch:
> >>>>> https://github.com/openedev/u-boot-amarula/commits/v2-WIP5
> >>>>
> >>>> Ugh, patchwork links would be nice.
> >>>
> >>> See here [1].
> >>>
> >>>>
> >>>> But for example
> >>>> https://github.com/openedev/u-boot-amarula/commit/91d8f9979420827942ca1f336df36504bd2c1943
> >>>>
> >>>> is quite inobvious, and I think buggy ...
> >>>>
> >>>>      else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts) != -1))
> >>>>
> >>>> sizeof(tmp_parts) != -1 will always be true.
> >>>
> >>> Indeed, I misplaced the closing parens, should be
> >>>
> >>>       else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts)) != -1)
> >>
> >> And the -1 too, even if you move the parenthesis, according to
> >> include/common.h .
> >
> > Travis-ci build fine for all, can we have a fix for this so-that we
> > move accordingly. these fixes are important and need to move for the
> > release.
>
> That patch is buggy and needs to be respun and retested. I don't think
> you can push known buggy patch into a release as a fix.

True, ie what my yesterday plan [1] but this seems to break some know
functionalities in MTD, can't we go with some immediate fix for this?
rest look fine and tested.
Miquel, Boris - Can you test this with fix and send.

[1] https://patchwork.ozlabs.org/patch/995872/

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Philipp Tomsich]

> On 13.11.2018, at 02:12, Tom Rini <trini@konsulko.com> wrote:
> 
> On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote:
>> On 11/12/2018 11:25 PM, Tom Rini wrote:
>>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote:
>>>> On 11/12/2018 10:40 PM, Tom Rini wrote:
>>>>> Hey all,
>>>>> 
>>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>>>> in the release and I believe didn't get them out before the end of his
>>>>> day, I'm letting everyone know now to expect the release tomorrow
>>>>> instead, thanks!
>>>> 
>>>> Will anyone have any chance to test those fixes to verify they didn't
>>>> break anything ?
>>> 
>>> Since they're obvious enough by inspection, I'm not worried about it.
>> 
>> Which patches are those ?
> 
> The ones in question?
> 
>>>> I believe this is yet another manifestation of the problems of the 2
>>>> month release cycle, which I think is too short and stressful.
>>> 
>>> And I believe that's a red herring.  All the same I am still considering
>>> changes.
>> 
>> I'd really like to know how do other maintainers feel about this 2 month
>> release cycle vs. for example 3 month like Linux does. I think the later
>> is about right, 2 months is too short.
> 
> Yes, I've asked before and there's a few people in the same camp as you,
> and there's a few people who like 2 months, and there's a large number
> of no strong opinions.  That's why I'm still thinking about changing
> things again.

My biggest concern is that there’s a large number of changes going into the
tree after rc1 and rc2: this makes is hard to maintain a next-tree as a custodian
and merge that early.  I have been holding off on changes post-rc1 for quality
reasons (so people have sufficient time to test), but am not maintaining a next
tree which makes things appear slow in being merged.

Possibly a next or staging tree on your level might resolve this: this could keep
the master in a testing-state from rc1 (or rc2) on and still push new changes
and features into a common next tree that might also get early test exposure.

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Wolfgang Denk]

Dear Jagan,

In message <CAMty3ZC_u=cigEYqj+fsurU8x=pqLCQ8HbVEsrA1qVFvR3ciWQ@mail.gmail.com> you wrote:
>
> > That patch is buggy and needs to be respun and retested. I don't think
> > you can push known buggy patch into a release as a fix.
> 
> True, ie what my yesterday plan [1] but this seems to break some know
> functionalities in MTD, can't we go with some immediate fix for this?

Your request makes no sense.  You just saw what "immediate fixes"
mean: adding untested code, which will make things not better, but
rahter worse, as you _think_ you have fixed something - while in
fact you have done the opposite.

It is _always_ a Good Thing to allow for sufficient time for
testing.  Even if this delays a release.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When the ax entered the forest, the trees said, "The handle is one of
us!"                                               -- Turkish proverb

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Jagan Teki]

On Tue, Nov 13, 2018 at 9:27 PM Wolfgang Denk <wd@denx.de> wrote:
>
> Dear Jagan,
>
> In message <CAMty3ZC_u=cigEYqj+fsurU8x=pqLCQ8HbVEsrA1qVFvR3ciWQ@mail.gmail.com> you wrote:
> >
> > > That patch is buggy and needs to be respun and retested. I don't think
> > > you can push known buggy patch into a release as a fix.
> >
> > True, ie what my yesterday plan [1] but this seems to break some know
> > functionalities in MTD, can't we go with some immediate fix for this?
>
> Your request makes no sense.  You just saw what "immediate fixes"
> mean: adding untested code, which will make things not better, but
> rahter worse, as you _think_ you have fixed something - while in
> fact you have done the opposite.
>
> It is _always_ a Good Thing to allow for sufficient time for
> testing.  Even if this delays a release.

These changes were fully tested, not an immediate changes. What I mean
a immediate fix here is not for the series, for the comment mentioned
by Marek about patch 1/5.

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Wolfgang Denk]

Dear Jagan,

In message <CAMty3ZAyEcWB8_WpkQev+V1NtFjXRRkuKkeowX0zbnAEUh99og@mail.gmail.com> you wrote:
>
> These changes were fully tested, not an immediate changes. What I mean
> a immediate fix here is not for the series, for the comment mentioned
> by Marek about patch 1/5.

Come on.  You mean this code:

>>	else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts) != -1))

was "fully tested"?  It may have been compile clean, but it
certainly was functionally broken, so it was NOT sufficiently
tested.  Just running travis is simply not enough to claim the stuff
was tested.

I'm shocked that you appear to think so.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
They're usually so busy thinking about what  happens  next  that  the
only  time they ever find out what is happening now is when they come
to look back on it.                 - Terry Pratchett, _Wyrd Sisters_

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Boris Brezillon]

Hello Wolfgang,

On Tue, 13 Nov 2018 21:36:17 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:

> On Tue, Nov 13, 2018 at 9:27 PM Wolfgang Denk <wd@denx.de> wrote:
> >
> > Dear Jagan,
> >
> > In message <CAMty3ZC_u=cigEYqj+fsurU8x=pqLCQ8HbVEsrA1qVFvR3ciWQ@mail.gmail.com> you wrote:  
> > >  
> > > > That patch is buggy and needs to be respun and retested. I don't think
> > > > you can push known buggy patch into a release as a fix.  
> > >
> > > True, ie what my yesterday plan [1] but this seems to break some know
> > > functionalities in MTD, can't we go with some immediate fix for this?  
> >
> > Your request makes no sense.  You just saw what "immediate fixes"
> > mean: adding untested code, which will make things not better, but
> > rahter worse, as you _think_ you have fixed something - while in
> > fact you have done the opposite.
> >
> > It is _always_ a Good Thing to allow for sufficient time for
> > testing.  Even if this delays a release.  
> 
> These changes were fully tested, not an immediate changes. What I mean
> a immediate fix here is not for the series, for the comment mentioned
> by Marek about patch 1/5.

More details about the current situation.

First of all, if you want to blame someone, it should be me not Jagan,
since I'm the one who insistently asked Jagan to apply the patch series
and send a PR to Tom. Now some explanation on what this series fixes.

The bug it fixes has been reported by Stefan Roese here. It was fixed
here [2]. It's also been tested by Stefan, I then fixed build failures
reported by Jagan [3] and finally the problem reported Marek yesterday
[4].

So yes, it's unfortunate that is took us two weeks to find those
issues, but, to be honest, I don't think we would have gotten more
reviews by delaying the series to the next release. Instead, the
request to merge this patchset in v2018.11 did trigger a review from
Marek who found a problem in the code.

Regarding the lack of testing, I understand your concern, but look at
the amount of config options we have for MTD or the various way we can
retrieve the mtdparts/mtdids info. I don't think we can easily test all
of these, or at least not in a reasonable amount of time. I'd love to
be proven wrong though.

Now, if [4] is a problem and you think it shouldn't be merged, let's not
delay the release for that. UBI will be buggy on setups with a
spi-nand, but I think we can live with that since it's a new feature
anyway.

Regards,

Boris

[1]http://patchwork.ozlabs.org/patch/990696/
[2]http://patchwork.ozlabs.org/project/uboot/list/?series=73381&archive=both&state=*
[3]http://patchwork.ozlabs.org/project/uboot/list/?series=75389&archive=both&state=*
[4]http://patchwork.ozlabs.org/project/uboot/list/?series=75687

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Jagan Teki]

On Wed, Nov 14, 2018 at 2:53 PM Wolfgang Denk <wd@denx.de> wrote:
>
> Dear Jagan,
>
> In message <CAMty3ZAyEcWB8_WpkQev+V1NtFjXRRkuKkeowX0zbnAEUh99og@mail.gmail.com> you wrote:
> >
> > These changes were fully tested, not an immediate changes. What I mean
> > a immediate fix here is not for the series, for the comment mentioned
> > by Marek about patch 1/5.
>
> Come on.  You mean this code:
>
> >>      else if (env_get_f("mtdparts", tmp_parts, sizeof(tmp_parts) != -1))
>
> was "fully tested"?  It may have been compile clean, but it
> certainly was functionally broken, so it was NOT sufficiently
> tested.  Just running travis is simply not enough to claim the stuff
> was tested.

One thing I can say here is, I didn't test 1/5 or either the series
since I don't have relevant hardware to produce the issue. I commented
"about testing" based on author testing, Tested-by credit and how much
this is needed for the release since I would trying to send the PR.

Sorry if you understand differently, but I'm still on the same page
what I mentioned in previous mail.

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Wolfgang Denk]

Dear Boris,

In message <20181114104745.26dde1fa@bbrezillon> you wrote:
>
> First of all, if you want to blame someone, it should be me not Jagan,
> since I'm the one who insistently asked Jagan to apply the patch series
> and send a PR to Tom. Now some explanation on what this series fixes.

Thanks - I understand the situation, and I'm not complaining abut
the bug itself (we all make mistakes), but about this "has been
fully tested" statement.

> Regarding the lack of testing, I understand your concern, but look at
> the amount of config options we have for MTD or the various way we can
> retrieve the mtdparts/mtdids info. I don't think we can easily test all
> of these, or at least not in a reasonable amount of time. I'd love to
> be proven wrong though.

If we wanted to be serious about testing (i. e. if sombody is
willing to invest a bit of time) we could test much more thoroughly.
Heiko has a number of tbot [1] based test cases running routinely on
a number of boards, and if you look at the number of bugs he found
and reported it cleanly shows how efficient this is.

If we were consequent, we would have implemented a test case for
this specific bug and added it to the list of routinely run tests.

[1] https://rahix.de/tbot/index.html


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Anatolij Gustschin]

On Mon, 12 Nov 2018 23:13:29 +0100
Marek Vasut marek.vasut at gmail.com wrote:

> On 11/12/2018 10:40 PM, Tom Rini wrote:
> > Hey all,
> > 
> > Since Jagan promise a v2 SPI PR for some build fixes that we should have
> > in the release and I believe didn't get them out before the end of his
> > day, I'm letting everyone know now to expect the release tomorrow
> > instead, thanks!  
> 
> Will anyone have any chance to test those fixes to verify they didn't
> break anything ?
> 
> I believe this is yet another manifestation of the problems of the 2
> month release cycle, which I think is too short and stressful.

Yes, and patches with fixes sometimes wait long time without review
or testing and miss the release, then people start to complain when
the released code is buggy. What about this [1] patch? Could someone
please review/test it? Can it be applied to v2018.11 ?

[1] https://patchwork.ozlabs.org/patch/985919

--
Anatolij

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Stefan Roese]

On 14.11.18 12:32, Anatolij Gustschin wrote:
> On Mon, 12 Nov 2018 23:13:29 +0100
> Marek Vasut marek.vasut at gmail.com wrote:
> 
>> On 11/12/2018 10:40 PM, Tom Rini wrote:
>>> Hey all,
>>>
>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>> in the release and I believe didn't get them out before the end of his
>>> day, I'm letting everyone know now to expect the release tomorrow
>>> instead, thanks!
>>
>> Will anyone have any chance to test those fixes to verify they didn't
>> break anything ?
>>
>> I believe this is yet another manifestation of the problems of the 2
>> month release cycle, which I think is too short and stressful.
> 
> Yes, and patches with fixes sometimes wait long time without review
> or testing and miss the release, then people start to complain when
> the released code is buggy. What about this [1] patch? Could someone
> please review/test it? Can it be applied to v2018.11 ?
> 
> [1] https://patchwork.ozlabs.org/patch/985919

Yes, this definitely is a valid fix and should be pulled.

But things like this (fixes missing the release) will always happen,
even if we have a 3 month release cycle. Perhaps we should think
(again?) about having some sort of stable releases, like 2018.11.1?
IIRC, we had something like this at some time. Then we could push
fixes like this one mentioned by Anatolij even after the original
release.

Thanks,
Stefan

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Marek Vasut]

On 11/14/2018 12:32 PM, Anatolij Gustschin wrote:
> On Mon, 12 Nov 2018 23:13:29 +0100
> Marek Vasut marek.vasut at gmail.com wrote:
> 
>> On 11/12/2018 10:40 PM, Tom Rini wrote:
>>> Hey all,
>>>
>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have
>>> in the release and I believe didn't get them out before the end of his
>>> day, I'm letting everyone know now to expect the release tomorrow
>>> instead, thanks!  
>>
>> Will anyone have any chance to test those fixes to verify they didn't
>> break anything ?
>>
>> I believe this is yet another manifestation of the problems of the 2
>> month release cycle, which I think is too short and stressful.
> 
> Yes, and patches with fixes sometimes wait long time without review
> or testing and miss the release, then people start to complain when
> the released code is buggy. What about this [1] patch? Could someone
> please review/test it? Can it be applied to v2018.11 ?
> 
> [1] https://patchwork.ozlabs.org/patch/985919

Yes, that's obviously a correct fix.

-- 
Best regards,
Marek Vasut

[U-Boot] [ANN] U-Boot v2018.11 delayed a day

[Tom Rini]

On Wed, Nov 14, 2018 at 12:40:58PM +0100, Stefan Roese wrote:
> On 14.11.18 12:32, Anatolij Gustschin wrote:
> >On Mon, 12 Nov 2018 23:13:29 +0100
> >Marek Vasut marek.vasut at gmail.com wrote:
> >
> >>On 11/12/2018 10:40 PM, Tom Rini wrote:
> >>>Hey all,
> >>>
> >>>Since Jagan promise a v2 SPI PR for some build fixes that we should have
> >>>in the release and I believe didn't get them out before the end of his
> >>>day, I'm letting everyone know now to expect the release tomorrow
> >>>instead, thanks!
> >>
> >>Will anyone have any chance to test those fixes to verify they didn't
> >>break anything ?
> >>
> >>I believe this is yet another manifestation of the problems of the 2
> >>month release cycle, which I think is too short and stressful.
> >
> >Yes, and patches with fixes sometimes wait long time without review
> >or testing and miss the release, then people start to complain when
> >the released code is buggy. What about this [1] patch? Could someone
> >please review/test it? Can it be applied to v2018.11 ?
> >
> >[1] https://patchwork.ozlabs.org/patch/985919
> 
> Yes, this definitely is a valid fix and should be pulled.

For the record, I saw that, then saw that fb01e07a95 was from January
2018 and decided that since we'd had the regression for a few releases,
one more wouldn't hurt.  Especially since it feels like there's
resistance to having code changes, in general and aside from the
PR-under-question, towards the end.  I guess I need to rework my own
patch criteria.

> But things like this (fixes missing the release) will always happen,
> even if we have a 3 month release cycle. Perhaps we should think
> (again?) about having some sort of stable releases, like 2018.11.1?
> IIRC, we had something like this at some time. Then we could push
> fixes like this one mentioned by Anatolij even after the original
> release.

We've done an occasional ".1" release for fairly big breakages of the
release.  If we want to do something like that more regularly I'd be
happy to read a proposal on how often / what kinds of changes go in.
Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181114/2b1b653a/attachment.sig>