[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-24

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-24

[Thomas Petazzoni]

Hello Titouan,

On Mon, 25 Nov 2019 10:13:05 +0100
Titouan Christophe <titouan.christophe@railnova.eu> wrote:

> >               name              | found by |        link to release-monitoring.org        |   version    |   upstream
> > -------------------------------+----------+----------------------------------------------+--------------+--------------
> >                           redis |  DISTRO  | https://release-monitoring.org/project/04181 | 5.0.5        | 5.0.7
> >   
> 
> This is lagging behind, Redis was already bumped to 5.0.6 one week ago, 
> and to 5.0.7 over the week-end :)

When a next branch exists, we use the next branch as the source of
information for what is the current version of each package in
Buildroot. We do this because typically, next is more "up to date" than
master.

However, in this specific case, redis was bumped to 5.0.7 in master,
but not in next, so until next gets merged back into master, our
tooling will think redis is at 5.0.5, because that's the version used
in next.

Perhaps this could be improved by grabbing both master and next, and
retaining the highest version between both, for each package. But oh
well, that's quite some additional complexity :/

Best regards,

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

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-24

[Titouan Christophe]

Hello Thomas,

On 11/25/19 11:56 AM, Thomas Petazzoni wrote:
> 
> When a next branch exists, we use the next branch as the source of
> information for what is the current version of each package in
> Buildroot. We do this because typically, next is more "up to date" than
> master.

Side question: what's the policy for committing to master vs. next ?

> 
> However, in this specific case, redis was bumped to 5.0.7 in master,
> but not in next, so until next gets merged back into master, our
> tooling will think redis is at 5.0.5, because that's the version used
> in next.


Thanks for the explanation, that makes much more sense.

> 
> Perhaps this could be improved by grabbing both master and next, and
> retaining the highest version between both, for each package. But oh
> well, that's quite some additional complexity :/

If you think that's worth it, I can have a look at that. Hence this 
shameless question: where does this code actually live ?

In Buildroot's repo:
$ git grep 'link to release-monitoring.org' | wc -l
0

> 
> Best regards,
> 
> Thomas
> 

Regards,

Titouan

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-24

[Thomas Petazzoni]

Hello,

On Mon, 25 Nov 2019 14:58:50 +0100
Titouan Christophe <titouan.christophe@railnova.eu> wrote:

> > When a next branch exists, we use the next branch as the source of
> > information for what is the current version of each package in
> > Buildroot. We do this because typically, next is more "up to date" than
> > master.  
> 
> Side question: what's the policy for committing to master vs. next ?

We have a 3 months development cycle:

 - First two months: only master exists, all changes go to master

 - We cut rc1, and then we have one month stabilization with multiple
   rc's until the final release

   During that period:

   * master takes only bug fixes, security fixes, build fixes
   * next takes major changes, version bumps, etc.

If you have a version bump that only fixes bugs/security problems, it
therefore goes into master. If you have a major version bump adding new
features and all, it goes to next.

> > Perhaps this could be improved by grabbing both master and next, and
> > retaining the highest version between both, for each package. But oh
> > well, that's quite some additional complexity :/  
> 
> If you think that's worth it, I can have a look at that. Hence this 
> shameless question: where does this code actually live ?
> 
> In Buildroot's repo:
> $ git grep 'link to release-monitoring.org' | wc -l
> 0

support/scripts/pkg-stats generates the JSON file that are then used to
send the notifications e-mails.

However, the change is not trivial, because support/scripts/pkg-stats
assumes it is running inside a Buildroot source tree. It doesn't have
by itself the understanding that Buildroot can have multiple branches.
So using the highest version between master and next requires a major
refactoring of how pkg-stats work, and how it is being executed.

Best regards,

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