[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Baruch Siach]

Hi Thomas,

The list of packages versions in Buildroot seems to be take from the master 
branch. All these packages were updated in the next branch. I think that when 
the next branch is active (i.e. has commits not in master), the script should 
look there instead of master.

baruch

On Mon, Aug 19, 2019 at 06:15:54AM -0000, Thomas Petazzoni wrote:
> Outdated packages
> =================
> 
> This is the list of packages for which a new version has been detected
> and for which you are a registered developer. Please help us improving
> the quality of Buildroot by bumping these packages to their latest
> version. Thanks!
> 
>              name              | found by |        link to release-monitoring.org        |   version    |   upstream  
> -------------------------------+----------+----------------------------------------------+--------------+--------------
>                       openipmi |  GUESS   | https://release-monitoring.org/project/02549 | 2.0.24       | 2.0.27      
>                          socat |  GUESS   | https://release-monitoring.org/project/04848 | 1.7.3.2      | 1.7.3.3     
>                         strace |  DISTRO  | https://release-monitoring.org/project/04897 | 5.0          | 5.2         
> 

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Thomas Petazzoni]

Hello,

On Mon, 19 Aug 2019 15:49:59 +0300
Baruch Siach <baruch@tkos.co.il> wrote:

> The list of packages versions in Buildroot seems to be take from the master 
> branch. All these packages were updated in the next branch. I think that when 
> the next branch is active (i.e. has commits not in master), the script should 
> look there instead of master.

Yes, this is a limitation of how we work right now. I'm not sure how to
handle this exactly at this point.

Should the results of http://autobuild.buildroot.net/stats/ and
http://autobuild.buildroot.net/stats/index.json use the next branch
when available ?

Having a look at the state of the master branch in terms of missing
version updates could also be helpful to detect packages for which
we're missing security updates.

So really, I'm not sure what is the best course of action here.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Arnout Vandecappelle]

On 19/08/2019 14:55, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 19 Aug 2019 15:49:59 +0300
> Baruch Siach <baruch@tkos.co.il> wrote:
> 
>> The list of packages versions in Buildroot seems to be take from the master 
>> branch. All these packages were updated in the next branch. I think that when 
>> the next branch is active (i.e. has commits not in master), the script should 
>> look there instead of master.
> 
> Yes, this is a limitation of how we work right now. I'm not sure how to
> handle this exactly at this point.
> 
> Should the results of http://autobuild.buildroot.net/stats/ and
> http://autobuild.buildroot.net/stats/index.json use the next branch
> when available ?
> 
> Having a look at the state of the master branch in terms of missing
> version updates could also be helpful to detect packages for which
> we're missing security updates.

 Not really, since we only show the highest release, so not anything from stable
branches. And we can assume that the version on next is >= the version on master.


 Regards,
 Arnout

> 
> So really, I'm not sure what is the best course of action here.
> 
> Thomas
> 

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Thomas Petazzoni]

On Mon, 19 Aug 2019 23:28:09 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

> > Yes, this is a limitation of how we work right now. I'm not sure how to
> > handle this exactly at this point.
> > 
> > Should the results of http://autobuild.buildroot.net/stats/ and
> > http://autobuild.buildroot.net/stats/index.json use the next branch
> > when available ?
> > 
> > Having a look at the state of the master branch in terms of missing
> > version updates could also be helpful to detect packages for which
> > we're missing security updates.  
> 
>  Not really, since we only show the highest release, so not anything from stable
> branches. And we can assume that the version on next is >= the version on master.

"we only show the highest release" -> release-monitoring.org doesn't
have the notion of "stable branches" from upstream or anything like
that. It even considers -rc versions to be more recent than a regular
official release.

But I see your point that anyway release-monitoring.org is only very
partially helping to track whether we need to update for security
reasons. A CVE-related tracking tool (such as what Matt Weber was
working on back then) would be better suited for this task.

If you agree with this, then perhaps the autobuild.b.o/stats/ page, and
the corresponding JSON output, should be generated based on the next
branch rather than the master branch.

Should I go ahead and make the change ?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 > "we only show the highest release" -> release-monitoring.org doesn't
 > have the notion of "stable branches" from upstream or anything like
 > that. It even considers -rc versions to be more recent than a regular
 > official release.

 > But I see your point that anyway release-monitoring.org is only very
 > partially helping to track whether we need to update for security
 > reasons. A CVE-related tracking tool (such as what Matt Weber was
 > working on back then) would be better suited for this task.

 > If you agree with this, then perhaps the autobuild.b.o/stats/ page, and
 > the corresponding JSON output, should be generated based on the next
 > branch rather than the master branch.

Presumably only if next exists (and then we have to remember to delete
it as soon as we merge it into master and not just let it linger until
the next release)?

 > Should I go ahead and make the change ?

It sounds sensible to me, yes.

-- 
Bye, Peter Korsgaard

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Arnout Vandecappelle]

On 20/08/2019 00:00, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
> 
> Hi,
> 
>  > "we only show the highest release" -> release-monitoring.org doesn't
>  > have the notion of "stable branches" from upstream or anything like
>  > that. It even considers -rc versions to be more recent than a regular
>  > official release.
> 
>  > But I see your point that anyway release-monitoring.org is only very
>  > partially helping to track whether we need to update for security
>  > reasons. A CVE-related tracking tool (such as what Matt Weber was
>  > working on back then) would be better suited for this task.
> 
>  > If you agree with this, then perhaps the autobuild.b.o/stats/ page, and
>  > the corresponding JSON output, should be generated based on the next
>  > branch rather than the master branch.
> 
> Presumably only if next exists (and then we have to remember to delete
> it as soon as we merge it into master and not just let it linger until
> the next release)?

 That would be a good idea anyway. I've known people to be confused by the
lingering next branch.


>  > Should I go ahead and make the change ?
> 
> It sounds sensible to me, yes.

 +1

 Regards,
 Arnout

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Arnout Vandecappelle]

On 20/08/2019 21:10, Arnout Vandecappelle wrote:
> 
> 
> On 20/08/2019 00:00, Peter Korsgaard wrote:
>>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
>>
>> Hi,
>>
>>  > "we only show the highest release" -> release-monitoring.org doesn't
>>  > have the notion of "stable branches" from upstream or anything like
>>  > that. It even considers -rc versions to be more recent than a regular
>>  > official release.
>>
>>  > But I see your point that anyway release-monitoring.org is only very
>>  > partially helping to track whether we need to update for security
>>  > reasons. A CVE-related tracking tool (such as what Matt Weber was
>>  > working on back then) would be better suited for this task.
>>
>>  > If you agree with this, then perhaps the autobuild.b.o/stats/ page, and
>>  > the corresponding JSON output, should be generated based on the next
>>  > branch rather than the master branch.
>>
>> Presumably only if next exists (and then we have to remember to delete
>> it as soon as we merge it into master and not just let it linger until
>> the next release)?
> 
>  That would be a good idea anyway. I've known people to be confused by the
> lingering next branch.

 Or perhaps it's a better idea to reverse the logic: on -rc1, create the stable
branch already, and treat master as next. IOW, avoid creating a next at all.

 But then we should probably also update the branches info for the autobuilders
to make sure the stable branch gets sufficient testing.

 Regards,
 Arnout

> 
> 
>>  > Should I go ahead and make the change ?
>>
>> It sounds sensible to me, yes.
> 
>  +1
> 
>  Regards,
>  Arnout
> 

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Yann E. MORIN]

Arnout, All,

On 2019-08-20 21:18 +0200, Arnout Vandecappelle spake thusly:
> On 20/08/2019 21:10, Arnout Vandecappelle wrote:
> > On 20/08/2019 00:00, Peter Korsgaard wrote:
> >>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
> >>  > "we only show the highest release" -> release-monitoring.org doesn't
> >>  > have the notion of "stable branches" from upstream or anything like
> >>  > that. It even considers -rc versions to be more recent than a regular
> >>  > official release.
> >>
> >>  > But I see your point that anyway release-monitoring.org is only very
> >>  > partially helping to track whether we need to update for security
> >>  > reasons. A CVE-related tracking tool (such as what Matt Weber was
> >>  > working on back then) would be better suited for this task.
> >>
> >>  > If you agree with this, then perhaps the autobuild.b.o/stats/ page, and
> >>  > the corresponding JSON output, should be generated based on the next
> >>  > branch rather than the master branch.
> >>
> >> Presumably only if next exists (and then we have to remember to delete
> >> it as soon as we merge it into master and not just let it linger until
> >> the next release)?
> > 
> >  That would be a good idea anyway. I've known people to be confused by the
> > lingering next branch.
> 
>  Or perhaps it's a better idea to reverse the logic: on -rc1, create the stable
> branch already, and treat master as next. IOW, avoid creating a next at all.

I would argue in favour of this solution.

>  But then we should probably also update the branches info for the autobuilders
> to make sure the stable branch gets sufficient testing.

This is relatively easy: just update http://autobuild.buildroot.org/branches
with new branches and new ratios.

Regards,
Yann E. MORIN.

>  Regards,
>  Arnout
> 
> > 
> > 
> >>  > Should I go ahead and make the change ?
> >>
> >> It sounds sensible to me, yes.
> > 
> >  +1
> > 
> >  Regards,
> >  Arnout
> > 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 >> Or perhaps it's a better idea to reverse the logic: on -rc1, create the stable
 >> branch already, and treat master as next. IOW, avoid creating a next at all.

 > I would argue in favour of this solution.

We could do that as well. We then need to merge in the other direction
(stable->master) to ensure fixes after rc1 (and updates to the CHANGES
file) are not dropped, and website changes needs to happen on master
rather than stable.

It seems a bit more complicated to me, but that might just be because I
have done the other way around for 10+ years by now ;)


 >> But then we should probably also update the branches info for the autobuilders
 >> to make sure the stable branch gets sufficient testing.

 > This is relatively easy: just update http://autobuild.buildroot.org/branches
 > with new branches and new ratios.

Yes, but this file in manually maintained and only accessible by Thomas,
right?

-- 
Bye, Peter Korsgaard

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Yann E. MORIN]

Peter, All,

On 2019-08-21 10:01 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>  >> Or perhaps it's a better idea to reverse the logic: on -rc1, create the stable
>  >> branch already, and treat master as next. IOW, avoid creating a next at all.
>  > I would argue in favour of this solution.
> We could do that as well. We then need to merge in the other direction
> (stable->master) to ensure fixes after rc1 (and updates to the CHANGES
> file) are not dropped,

Well, usual version control best practices suggests the opposite: all
fixes are done on master, and when relevant, back-ported to the stable
branch(es).

This is no different than what you do today when you backport changes
from master to the stable branches, except it happens right from -rc1
instead of after the final release. It is the exact same process.

> and website changes needs to happen on master
> rather than stable.

But that's already the case, no?

> It seems a bit more complicated to me, but that might just be because I
> have done the other way around for 10+ years by now ;)

Yeah, I know habbits, as bad as they might be, are hard to break! ;-p

>  >> But then we should probably also update the branches info for the autobuilders
>  >> to make sure the stable branch gets sufficient testing.
> 
>  > This is relatively easy: just update http://autobuild.buildroot.org/branches
>  > with new branches and new ratios.
> 
> Yes, but this file in manually maintained and only accessible by Thomas,
> right?

How would that be different from today? I would say that today, for each
release cycle, there are two changes:

  - one to introduce next in the list (after -rc1)
  - one to introduce the new stable rbanch and remove next and the
    oldest stable branch (after the release)

with the proposed change, there would be a single change per release:

  - one to add the new stable branch and remove the oldest stable branch
    (after -rc1)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 >> We could do that as well. We then need to merge in the other direction
 >> (stable->master) to ensure fixes after rc1 (and updates to the CHANGES
 >> file) are not dropped,

 > Well, usual version control best practices suggests the opposite: all
 > fixes are done on master, and when relevant, back-ported to the stable
 > branch(es).

 > This is no different than what you do today when you backport changes
 > from master to the stable branches, except it happens right from -rc1
 > instead of after the final release. It is the exact same process.

Correct.

 >> and website changes needs to happen on master
 >> rather than stable.

 > But that's already the case, no?

Yes. This does mean that the website copy in the tarball doesn't match
the real website for "normal" releases, but that isn't really a big
deal.


 >> It seems a bit more complicated to me, but that might just be because I
 >> have done the other way around for 10+ years by now ;)

 > Yeah, I know habbits, as bad as they might be, are hard to break! ;-p

Heh. Notice that the choice for a next branch rather than branching of
for releases was done on purpose to motivate people to focus more on the
upcoming release rather than new stuff. I think this has largely
succeeded, and I am somewhat afraid of a shift of focus if we change
this. I see very little outside contributions to the stable/lts
branches.


 >> >> But then we should probably also update the branches info for the autobuilders
 >> >> to make sure the stable branch gets sufficient testing.
 >> 
 >> > This is relatively easy: just update http://autobuild.buildroot.org/branches
 >> > with new branches and new ratios.
 >> 
 >> Yes, but this file in manually maintained and only accessible by Thomas,
 >> right?

 > How would that be different from today? I would say that today, for each
 > release cycle, there are two changes:

 >   - one to introduce next in the list (after -rc1)
 >   - one to introduce the new stable rbanch and remove next and the
 >     oldest stable branch (after the release)

 > with the proposed change, there would be a single change per release:

 >   - one to add the new stable branch and remove the oldest stable branch
 >     (after -rc1)

But that doesn't take the weights into consideration, so we would end up
spending most of the autobuilder time on master (E.G. what we now call
next).

Anyway, I am OK with giving it a try for 2019.11, but I'm not completely
convinced about it.

-- 
Bye, Peter Korsgaard

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Arnout Vandecappelle]

On 21/08/2019 12:03, Peter Korsgaard wrote:
>>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
> Hi,
> 
>  >> We could do that as well. We then need to merge in the other direction
>  >> (stable->master) to ensure fixes after rc1 (and updates to the CHANGES
>  >> file) are not dropped,
> 
>  > Well, usual version control best practices suggests the opposite: all
>  > fixes are done on master, and when relevant, back-ported to the stable
>  > branch(es).
> 
>  > This is no different than what you do today when you backport changes
>  > from master to the stable branches, except it happens right from -rc1
>  > instead of after the final release. It is the exact same process.

 However, the cherry-picking process is much labour-intensive than just merging
next into master. And we expect a *lot* of patches to still go into the stable
branch during the release month. So if we choose this approach, we'll be
applying onto stable and merging into master.

> 
> Correct.
> 
>  >> and website changes needs to happen on master
>  >> rather than stable.
> 
>  > But that's already the case, no?
> 
> Yes. This does mean that the website copy in the tarball doesn't match
> the real website for "normal" releases, but that isn't really a big
> deal.

 The website in the tarball only matches the real website in the time between
the release and the next modification to the website. For 2019.05, that time was
15 minutes (update of news.html with the new release).

>  >> It seems a bit more complicated to me, but that might just be because I
>  >> have done the other way around for 10+ years by now ;)
> 
>  > Yeah, I know habbits, as bad as they might be, are hard to break! ;-p
> 
> Heh. Notice that the choice for a next branch rather than branching of
> for releases was done on purpose to motivate people to focus more on the
> upcoming release rather than new stuff. I think this has largely
> succeeded, and I am somewhat afraid of a shift of focus if we change
> this. I see very little outside contributions to the stable/lts
> branches.

 I'm not sure if this focus on the upcoming release is really related to the
state of the master branch. I think the key factor is that the branch for the
upcoming release gets most of the testing in the autobuilders.

 Actually, I think the inverse effect is bigger. We regularly see patches that
are for next (but not marked as such) but that don't actually apply to next,
because they've been created on master. I expect that if we swap the branches,
we'll get a lot less of that: patches that are for the upcoming release either
apply to both branches (95% of the cases), or the contributor is likely to have
intentionally created it for the upcoming release (e.g. because it is a patch
cherry-pick instead of a version bump).


>  >> >> But then we should probably also update the branches info for the autobuilders
>  >> >> to make sure the stable branch gets sufficient testing.
>  >> 
>  >> > This is relatively easy: just update http://autobuild.buildroot.org/branches
>  >> > with new branches and new ratios.
>  >> 
>  >> Yes, but this file in manually maintained and only accessible by Thomas,
>  >> right?
> 
>  > How would that be different from today? I would say that today, for each
>  > release cycle, there are two changes:
> 
>  >   - one to introduce next in the list (after -rc1)
>  >   - one to introduce the new stable rbanch and remove next and the
>  >     oldest stable branch (after the release)
> 
>  > with the proposed change, there would be a single change per release:
> 
>  >   - one to add the new stable branch and remove the oldest stable branch
>  >     (after -rc1)
> 
> But that doesn't take the weights into consideration, so we would end up
> spending most of the autobuilder time on master (E.G. what we now call
> next).

 Indeed, we still need both actions: one to add the new stable branch with a
large weight, and one to reset the weight of master.


> Anyway, I am OK with giving it a try for 2019.11, but I'm not completely
> convinced about it.

 Sounds like a plan!

 Regards,
 Arnout

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Thomas Petazzoni]

Hello,

On Wed, 21 Aug 2019 12:03:46 +0200
Peter Korsgaard <peter@korsgaard.com> wrote:

>  >   - one to add the new stable branch and remove the oldest stable branch
>  >     (after -rc1)  
> 
> But that doesn't take the weights into consideration, so we would end up
> spending most of the autobuilder time on master (E.G. what we now call
> next).
> 
> Anyway, I am OK with giving it a try for 2019.11, but I'm not completely
> convinced about it.

I also don't really see the benefit(s) of this change. To me, it seems
a lot easier to just adjust the logic that generates the package
statistics to use the next branch when it is available. The rest of our
existing workflow can continue to work as-is. It's already confusing
for some of our contributors, if in addition to that we keep changing
our workflow for gratuitous reasons, it is not going to help.

So I'm not really in favor of changing the workflow, unless there is
some clear benefit to it.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 >> Anyway, I am OK with giving it a try for 2019.11, but I'm not completely
 >> convinced about it.

 > I also don't really see the benefit(s) of this change. To me, it seems
 > a lot easier to just adjust the logic that generates the package
 > statistics to use the next branch when it is available. The rest of our
 > existing workflow can continue to work as-is. It's already confusing
 > for some of our contributors, if in addition to that we keep changing
 > our workflow for gratuitous reasons, it is not going to help.

 > So I'm not really in favor of changing the workflow, unless there is
 > some clear benefit to it.

As is probably clear from the discussion, neither am I. Do we really
think that changing the workflow around next/stable will bring any
significant improvements in clarity/development speed/..?

-- 
Bye, Peter Korsgaard

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Thomas Petazzoni]

Hello,

On Mon, 19 Aug 2019 15:49:59 +0300
Baruch Siach <baruch@tkos.co.il> wrote:

> The list of packages versions in Buildroot seems to be take from the master 
> branch. All these packages were updated in the next branch. I think that when 
> the next branch is active (i.e. has commits not in master), the script should 
> look there instead of master.

I have modified the logic. Now pkg-stats is run with the data from the
next branch when it exists, otherwise using the data of the master
branch. So we simply need to drop the next branch from the official Git
repo when a release is done to have pkg-stats be back in using data
from the master branch.

I have not re-generated the pkg-stats data, so it will have an effect
only tomorrow.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Thomas Petazzoni]

Hello Adrien,

+Buildroot mailing list in Cc.

On Mon, 19 Aug 2019 12:35:19 +0200
Adrien Gallou?t <adrien@gallouet.fr> wrote:

> > This is the list of packages for which a new version has been detected
> > and for which you are a registered developer. Please help us improving
> > the quality of Buildroot by bumping these packages to their latest
> > version. Thanks!
> >
> >              name              | found by |        link to
> > release-monitoring.org        |   version    |   upstream
> >
> > -------------------------------+----------+----------------------------------------------+--------------+--------------
> >                           bird |  GUESS   |
> > https://release-monitoring.org/project/00192 | 2.0.4        | 2.0.5
> >
> > --
> > http://autobuild.buildroot.net  
> 
> 
> This is very nice to have this kind of automatic alerts. Well done ;)

Glad to hear you're find those automatic notifications useful. This was
all done by Victor Huesca (in Cc) as part of his internship at Bootlin
this summer, working on Buildroot topics.

> I was aware of this release and tested it the first day and I had lot of
> issue with it, I expect a bugfix release.
> Do you prefer to be syncd everytime?

It is up to you as a developer/maintainer of this package to decide
when it is appropriate to update the version. If you know 2.0.5 has a
number of issues that will be fixed in future releases, you can
perfectly wait until those releases become available. You will only
receive this notification e-mail once a week in the mean time, which I
believe is reasonable.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com