[Buildroot] Bumping packages: some comments/suggestions

[Buildroot] Bumping packages: some comments/suggestions

[Thomas Petazzoni]

Hello Jerzy and Axel,

Recently, both of you have worked on and contributed a number of
patches bumping a significant number of Buildroot packages. This is of
course really great, and I'd like to thank you for those contributions.

That being said, I would have two suggestions:

 *) It would be great if you could check that the reverse dependencies
    of the package you're bumping still continue to build. For example,
    Axel bumped 'ortp', but didn't realize bumping it would break
    the linphone and mediastreamer. While we certainly cannot expect
    contributors to test package bumps in all possible configurations
    (especially for packages having a large number of
    reverse dependencies), checking at least a few of them is a good
    idea. Also, when bumping from one major release to another (such as
    berkeleydb 5.x to berkeleydb 6.x), even more care should be taken.

 *) To make this "bumping" effort a bit more systematic, I believe it
    would be useful to introduce an infrastructure in Buildroot to
    automatically check if upstream has a new package. In many cases,
    the upstream site has a directory with all the different versions
    of the tarball, so checking if there's a newer one in an automated
    way would be possible. If we do this for many packages, then we can
    run a script every day, and check if there are new upstream
    releases available. Debian has such a mechanism with the 'watch'
    mechanism (see https://wiki.debian.org/debian/watch/). Gentoo has
    the euscan utility (see https://github.com/iksaif/euscan). It would
    be nice having something like this, that we could integrate in the
    Buildroot per-package stats at
    http://autobuild.buildroot.org/stats/ to get a clear vision of
    which packages need to be upgraded. If one of you is interested in
    doing this, it'd be great!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[Axel Lin]

2013/10/13 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Hello Jerzy and Axel,
>
> Recently, both of you have worked on and contributed a number of
> patches bumping a significant number of Buildroot packages. This is of
> course really great, and I'd like to thank you for those contributions.
>
> That being said, I would have two suggestions:
>
>  *) It would be great if you could check that the reverse dependencies
>     of the package you're bumping still continue to build. For example,
>     Axel bumped 'ortp', but didn't realize bumping it would break
>     the linphone and mediastreamer. While we certainly cannot expect
This is my bad.
I did try to compile ortp with various combination of build config.
I didn't realize the reverse dependencies issue when
I sent the patch bumping ortp version.
A lesson learnt. I'll be more careful when bump version.

>     contributors to test package bumps in all possible configurations
>     (especially for packages having a large number of
>     reverse dependencies), checking at least a few of them is a good
>     idea. Also, when bumping from one major release to another (such as
>     berkeleydb 5.x to berkeleydb 6.x), even more care should be taken.
Also my bad. Will be checking licenses as well when bump versions.

Regards,
Axel

>
>  *) To make this "bumping" effort a bit more systematic, I believe it
>     would be useful to introduce an infrastructure in Buildroot to
>     automatically check if upstream has a new package. In many cases,
>     the upstream site has a directory with all the different versions
>     of the tarball, so checking if there's a newer one in an automated
>     way would be possible. If we do this for many packages, then we can
>     run a script every day, and check if there are new upstream
>     releases available. Debian has such a mechanism with the 'watch'
>     mechanism (see https://wiki.debian.org/debian/watch/). Gentoo has
>     the euscan utility (see https://github.com/iksaif/euscan). It would
>     be nice having something like this, that we could integrate in the
>     Buildroot per-package stats at
>     http://autobuild.buildroot.org/stats/ to get a clear vision of
>     which packages need to be upgraded. If one of you is interested in
>     doing this, it'd be great!
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[Thomas Petazzoni]

Dear Axel Lin,

On Sun, 13 Oct 2013 18:44:31 +0800, Axel Lin wrote:

> > Recently, both of you have worked on and contributed a number of
> > patches bumping a significant number of Buildroot packages. This is of
> > course really great, and I'd like to thank you for those contributions.
> >
> > That being said, I would have two suggestions:
> >
> >  *) It would be great if you could check that the reverse dependencies
> >     of the package you're bumping still continue to build. For example,
> >     Axel bumped 'ortp', but didn't realize bumping it would break
> >     the linphone and mediastreamer. While we certainly cannot expect
> This is my bad.
> I did try to compile ortp with various combination of build config.
> I didn't realize the reverse dependencies issue when
> I sent the patch bumping ortp version.
> A lesson learnt. I'll be more careful when bump version.
> 
> >     contributors to test package bumps in all possible configurations
> >     (especially for packages having a large number of
> >     reverse dependencies), checking at least a few of them is a good
> >     idea. Also, when bumping from one major release to another (such as
> >     berkeleydb 5.x to berkeleydb 6.x), even more care should be taken.
> Also my bad. Will be checking licenses as well when bump versions.

Thanks. Note that my comments were really meant as suggestions to
improve your contributions: these will continue to be very welcome.

> >  *) To make this "bumping" effort a bit more systematic, I believe it
> >     would be useful to introduce an infrastructure in Buildroot to
> >     automatically check if upstream has a new package. In many cases,
> >     the upstream site has a directory with all the different versions
> >     of the tarball, so checking if there's a newer one in an automated
> >     way would be possible. If we do this for many packages, then we can
> >     run a script every day, and check if there are new upstream
> >     releases available. Debian has such a mechanism with the 'watch'
> >     mechanism (see https://wiki.debian.org/debian/watch/). Gentoo has
> >     the euscan utility (see https://github.com/iksaif/euscan). It would
> >     be nice having something like this, that we could integrate in the
> >     Buildroot per-package stats at
> >     http://autobuild.buildroot.org/stats/ to get a clear vision of
> >     which packages need to be upgraded. If one of you is interested in
> >     doing this, it'd be great!

Any opinion about this? I believe it would make more sense to invest
time doing this than doing many many bumps on all packages.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[Thomas De Schampheleire]

Hi Thomas,

On Sun, Oct 13, 2013 at 3:42 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[..]
>
>> >  *) To make this "bumping" effort a bit more systematic, I believe it
>> >     would be useful to introduce an infrastructure in Buildroot to
>> >     automatically check if upstream has a new package. In many cases,
>> >     the upstream site has a directory with all the different versions
>> >     of the tarball, so checking if there's a newer one in an automated
>> >     way would be possible. If we do this for many packages, then we can
>> >     run a script every day, and check if there are new upstream
>> >     releases available. Debian has such a mechanism with the 'watch'
>> >     mechanism (see https://wiki.debian.org/debian/watch/). Gentoo has
>> >     the euscan utility (see https://github.com/iksaif/euscan). It would
>> >     be nice having something like this, that we could integrate in the
>> >     Buildroot per-package stats at
>> >     http://autobuild.buildroot.org/stats/ to get a clear vision of
>> >     which packages need to be upgraded. If one of you is interested in
>> >     doing this, it'd be great!
>
> Any opinion about this? I believe it would make more sense to invest
> time doing this than doing many many bumps on all packages.

I assume you're only talking about a way to automatically _detect_
that there are new versions of a given package, and the actual update
in buildroot is still done manually, right?

Best regards,
Thomas

[Buildroot] Bumping packages: some comments/suggestions

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sun, 13 Oct 2013 17:01:48 +0200, Thomas De Schampheleire wrote:

> > Any opinion about this? I believe it would make more sense to invest
> > time doing this than doing many many bumps on all packages.
> 
> I assume you're only talking about a way to automatically _detect_
> that there are new versions of a given package, and the actual update
> in buildroot is still done manually, right?

Of course. But this way, we would have some kind of "dashboard" showing
us which packages might benefit from a bump.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[Jerzy Grzegorek]

Hi Thomas,


> Hello Jerzy and Axel,
>
> Recently, both of you have worked on and contributed a number of
> patches bumping a significant number of Buildroot packages. This is of
> course really great, and I'd like to thank you for those contributions.
>
> That being said, I would have two suggestions:
>
>   *) It would be great if you could check that the reverse dependencies
>      of the package you're bumping still continue to build. For example,
>      Axel bumped 'ortp', but didn't realize bumping it would break
>      the linphone and mediastreamer. While we certainly cannot expect
>      contributors to test package bumps in all possible configurations
>      (especially for packages having a large number of
>      reverse dependencies), checking at least a few of them is a good
>      idea. Also, when bumping from one major release to another (such as
>      berkeleydb 5.x to berkeleydb 6.x), even more care should be taken.
>
>   *) To make this "bumping" effort a bit more systematic, I believe it
>      would be useful to introduce an infrastructure in Buildroot to
>      automatically check if upstream has a new package. In many cases,
>      the upstream site has a directory with all the different versions
>      of the tarball, so checking if there's a newer one in an automated
>      way would be possible. If we do this for many packages, then we can
>      run a script every day, and check if there are new upstream
>      releases available. Debian has such a mechanism with the 'watch'
>      mechanism (see https://wiki.debian.org/debian/watch/). Gentoo has
>      the euscan utility (see https://github.com/iksaif/euscan). It would
>      be nice having something like this, that we could integrate in the
>      Buildroot per-package stats at
>      http://autobuild.buildroot.org/stats/ to get a clear vision of
>      which packages need to be upgraded. If one of you is interested in
>      doing this, it'd be great!

Thanks for your suggestions.
Do you mean something like this ?

Package name        Current version       New upstream releases Reverse 
dependencies
======================================================================================= 

...
apr ............... 1.4.6 ........................................ 
apr-util log4cxx
apr ..................................... 1.4.8
apr-util .......... 1.4.1
apr-util ................................ 1.5.1
apr-util ................................ 1.5.2
...

Regards,
Jerzy


> Best regards,
>
> Thomas

[Buildroot] Bumping packages: some comments/suggestions

[Thomas Petazzoni]

Dear Jerzy Grzegorek,

On Sun, 13 Oct 2013 23:04:47 +0200, Jerzy Grzegorek wrote:
> 
> 
> Hi Thomas,
> 
> 
> > Hello Jerzy and Axel,
> >
> > Recently, both of you have worked on and contributed a number of
> > patches bumping a significant number of Buildroot packages. This is of
> > course really great, and I'd like to thank you for those contributions.
> >
> > That being said, I would have two suggestions:
> >
> >   *) It would be great if you could check that the reverse dependencies
> >      of the package you're bumping still continue to build. For example,
> >      Axel bumped 'ortp', but didn't realize bumping it would break
> >      the linphone and mediastreamer. While we certainly cannot expect
> >      contributors to test package bumps in all possible configurations
> >      (especially for packages having a large number of
> >      reverse dependencies), checking at least a few of them is a good
> >      idea. Also, when bumping from one major release to another (such as
> >      berkeleydb 5.x to berkeleydb 6.x), even more care should be taken.
> >
> >   *) To make this "bumping" effort a bit more systematic, I believe it
> >      would be useful to introduce an infrastructure in Buildroot to
> >      automatically check if upstream has a new package. In many cases,
> >      the upstream site has a directory with all the different versions
> >      of the tarball, so checking if there's a newer one in an automated
> >      way would be possible. If we do this for many packages, then we can
> >      run a script every day, and check if there are new upstream
> >      releases available. Debian has such a mechanism with the 'watch'
> >      mechanism (see https://wiki.debian.org/debian/watch/). Gentoo has
> >      the euscan utility (see https://github.com/iksaif/euscan). It would
> >      be nice having something like this, that we could integrate in the
> >      Buildroot per-package stats at
> >      http://autobuild.buildroot.org/stats/ to get a clear vision of
> >      which packages need to be upgraded. If one of you is interested in
> >      doing this, it'd be great!
> 
> Thanks for your suggestions.
> Do you mean something like this ?
> 
> Package name        Current version       New upstream releases Reverse 
> dependencies
> ======================================================================================= 
> 
> ...
> apr ............... 1.4.6 ........................................ 
> apr-util log4cxx
> apr ..................................... 1.4.8
> apr-util .......... 1.4.1
> apr-util ................................ 1.5.1
> apr-util ................................ 1.5.2

I'm not sure listing all reverse dependencies will actually be useful
and/or possible. But yet, the idea is to add a mechanism that allows to
automatically check, for a given package, if there is a new upstream
version available.

Also, I believe there is no need to list multiple "new" upstream
releases (as you did for apr-util above), listing the latest one
available is fine.

Again, for now, the core of the problem is to be able to *detect* when
an upstream version is available for a given package. Once that is
done, we will see at integrating that into the statistics page I
mentioned earlier, and do all the automated execution.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[Jeremy Rosen]

> 
> Again, for now, the core of the problem is to be able to *detect*
> when
> an upstream version is available for a given package. Once that is
> done, we will see at integrating that into the statistics page I
> mentioned earlier, and do all the automated execution.
> 


two ideas that might or might not be good ideas but are worth discussing
early :

* try to automatically build the new version to see if it is an "easy
bump" or a "hard bump" and document the result

* ping the last person(s) that touch the package (git has facilities to
find them, I think it's called git-contribute) when a new version is
available


both have good and bad sides, thus worth discussing...

[Buildroot] Bumping packages: some comments/suggestions

[Thomas Petazzoni]

Dear Jeremy Rosen,

On Mon, 14 Oct 2013 09:40:46 +0200 (CEST), Jeremy Rosen wrote:

> two ideas that might or might not be good ideas but are worth discussing
> early :
> 
> * try to automatically build the new version to see if it is an "easy
> bump" or a "hard bump" and document the result
> 
> * ping the last person(s) that touch the package (git has facilities to
> find them, I think it's called git-contribute) when a new version is
> available
> 
> both have good and bad sides, thus worth discussing...

Agreed. But all of this first requires the ability to detect that a new
version is available.

I must say I'm not a big fan of the automatic build, which may
encourage people to do "careless" bump, i.e version bumps without
looking at least a little bit at what changed, and taking a set back by
looking at the version number, or the project web site, to see if the
version bump is small, or major.

For the second one, I agree. We have discussed a few times having the
notion of package maintainers. Probably something that will be worth
discussing at this time.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[Jeremy Rosen]

> 
> I must say I'm not a big fan of the automatic build, which may
> encourage people to do "careless" bump, i.e version bumps without
> looking at least a little bit at what changed, and taking a set back
> by
> looking at the version number, or the project web site, to see if the
> version bump is small, or major.
> 

yeah, that's the "might not be a good idea" part... I was more thinking
on the line of "this is a minor release and it compiles correctly, it's
probably an easy job to test and bump" i.e for the case of minor/security
releases upstream. It's a balance between helping maintainers work fast,
helping project managers see low hanging fruites and making sure people
are not too lazy...

> For the second one, I agree. We have discussed a few times having the
> notion of package maintainers. Probably something that will be worth
> discussing at this time.
> 
> Best regards,
> 
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> 

[Buildroot] Bumping packages: some comments/suggestions

[Thomas De Schampheleire]

On Mon, Oct 14, 2013 at 11:38 AM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
[..]
>
> yeah, that's the "might not be a good idea" part... I was more thinking
> on the line of "this is a minor release and it compiles correctly, it's
> probably an easy job to test and bump" i.e for the case of minor/security
> releases upstream. It's a balance between helping maintainers work fast,
> helping project managers see low hanging fruites and making sure people
> are not too lazy...
>
[..]

What I wanted to add in this discussion is this: if there are people
out there that have time for some buildroot development but they have
no clear goal of their own, they can among others choose between
package bumps and fixing autobuild failures.
While there certainly is value in package bumping, I hope that not all
of these people jump onto the bump-train and instead help with the
autobuild failures. We still hope to get to 0 failures at some point,
and bumping packages all the time will most of the time only add new
problems.

Best regards,
Thomas

[Buildroot] Bumping packages: some comments/suggestions

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Mon, 14 Oct 2013 12:02:35 +0200, Thomas De Schampheleire wrote:

> What I wanted to add in this discussion is this: if there are people
> out there that have time for some buildroot development but they have
> no clear goal of their own, they can among others choose between
> package bumps and fixing autobuild failures.
> While there certainly is value in package bumping, I hope that not all
> of these people jump onto the bump-train and instead help with the
> autobuild failures. We still hope to get to 0 failures at some point,
> and bumping packages all the time will most of the time only add new
> problems.

I definitely agree that looking and fixing autobuilder failures is also
a very important goal. Contributions in this area are very very welcome.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[arnaud aujon]

Hi,

I'm interested in developing an automatic way to know if a package needs to
be bumped.
I'm a new contributor to buildroot (just sent a patch to add a new
package,  well 3 patches because I had trouble with git send-email...), if
no one else have time to do it, I'll be happy to help Buildroot this way.

Regards,

Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131014/f2598ab2/attachment.html>

[Buildroot] Bumping packages: some comments/suggestions

[rjbarnet at rockwellcollins.com]

Thomas P, Jeremy R, All,

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote on 
10/14/2013 04:30:00 AM:

> Dear Jeremy Rosen,
> 
> On Mon, 14 Oct 2013 09:40:46 +0200 (CEST), Jeremy Rosen wrote:
> 
> > two ideas that might or might not be good ideas but are worth 
discussing
> > early :
> > 
> > * try to automatically build the new version to see if it is an "easy
> > bump" or a "hard bump" and document the result
> > 
> > * ping the last person(s) that touch the package (git has facilities 
to
> > find them, I think it's called git-contribute) when a new version is
> > available
> > 
> > both have good and bad sides, thus worth discussing...
> 
> Agreed. But all of this first requires the ability to detect that a new
> version is available.
> 
> I must say I'm not a big fan of the automatic build, which may
> encourage people to do "careless" bump, i.e version bumps without
> looking at least a little bit at what changed, and taking a set back by
> looking at the version number, or the project web site, to see if the
> version bump is small, or major.
> 
> For the second one, I agree. We have discussed a few times having the
> notion of package maintainers. Probably something that will be worth
> discussing at this time.

Sounds like a good topic for the Buildroot Developer Days...

Thanks,
-Ryan

[Buildroot] Bumping packages: some comments/suggestions

[Thomas Petazzoni]

Arnaud,

On Mon, 14 Oct 2013 14:58:19 +0200, arnaud aujon wrote:

> I'm interested in developing an automatic way to know if a package needs to
> be bumped.
> I'm a new contributor to buildroot (just sent a patch to add a new
> package,  well 3 patches because I had trouble with git send-email...), if
> no one else have time to do it, I'll be happy to help Buildroot this way.

Until now, nobody has volunteered to work on this, so if you're
interested, feel free to start prototyping things. I believe a helper
script (in Python?), called from the Buildroot makefiles, is probably
the best way: doing all this logic purely in make might be too
complicated.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[arnaud aujon]

All right, I will start working on a python script. I keep you in touch.


2013/10/14 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> Arnaud,
>
> On Mon, 14 Oct 2013 14:58:19 +0200, arnaud aujon wrote:
>
> > I'm interested in developing an automatic way to know if a package needs
> to
> > be bumped.
> > I'm a new contributor to buildroot (just sent a patch to add a new
> > package,  well 3 patches because I had trouble with git send-email...),
> if
> > no one else have time to do it, I'll be happy to help Buildroot this way.
>
> Until now, nobody has volunteered to work on this, so if you're
> interested, feel free to start prototyping things. I believe a helper
> script (in Python?), called from the Buildroot makefiles, is probably
> the best way: doing all this logic purely in make might be too
> complicated.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131014/07b83ec6/attachment.html>

[Buildroot] Bumping packages: some comments/suggestions

[Arnout Vandecappelle]

On 14/10/13 12:02, Thomas De Schampheleire wrote:
> On Mon, Oct 14, 2013 at 11:38 AM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
> [..]
>>
>> yeah, that's the "might not be a good idea" part... I was more thinking
>> on the line of "this is a minor release and it compiles correctly, it's
>> probably an easy job to test and bump" i.e for the case of minor/security
>> releases upstream. It's a balance between helping maintainers work fast,
>> helping project managers see low hanging fruites and making sure people
>> are not too lazy...
>>
> [..]
>
> What I wanted to add in this discussion is this: if there are people
> out there that have time for some buildroot development but they have
> no clear goal of their own, they can among others choose between
> package bumps and fixing autobuild failures.
> While there certainly is value in package bumping, I hope that not all
> of these people jump onto the bump-train and instead help with the
> autobuild failures. We still hope to get to 0 failures at some point,
> and bumping packages all the time will most of the time only add new
> problems.

  I'm also not too hot on version bumping just for the sake of bumping. 
Version bumps should be done when they're useful for someone, e.g. 
because a feature or bugfix is added. If it's useful to you, then you'll 
obviously test if it still works correctly.


  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Bumping packages: some comments/suggestions

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Mon, 14 Oct 2013 23:55:17 +0200, Arnout Vandecappelle wrote:

> > What I wanted to add in this discussion is this: if there are people
> > out there that have time for some buildroot development but they have
> > no clear goal of their own, they can among others choose between
> > package bumps and fixing autobuild failures.
> > While there certainly is value in package bumping, I hope that not all
> > of these people jump onto the bump-train and instead help with the
> > autobuild failures. We still hope to get to 0 failures at some point,
> > and bumping packages all the time will most of the time only add new
> > problems.
> 
>   I'm also not too hot on version bumping just for the sake of bumping. 
> Version bumps should be done when they're useful for someone, e.g. 
> because a feature or bugfix is added. If it's useful to you, then you'll 
> obviously test if it still works correctly.

I understand this point of view, but on the other hand, it's not really
nice to have packages that have very old versions. For "core" stuff
that isn't necessarily very easy to bump (think Qt, Gtk, X.org and
things like that), it's quite important that the core Buildroot
community keeps that up to date, because this is difficult to do for
newcomers, and this is what people will look at to see if Buildroot is
well-maintained and active.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Bumping packages: some comments/suggestions

[Arnout Vandecappelle]

On 15/10/13 09:34, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Mon, 14 Oct 2013 23:55:17 +0200, Arnout Vandecappelle wrote:
>
>>> What I wanted to add in this discussion is this: if there are people
>>> out there that have time for some buildroot development but they have
>>> no clear goal of their own, they can among others choose between
>>> package bumps and fixing autobuild failures.
>>> While there certainly is value in package bumping, I hope that not all
>>> of these people jump onto the bump-train and instead help with the
>>> autobuild failures. We still hope to get to 0 failures at some point,
>>> and bumping packages all the time will most of the time only add new
>>> problems.
>>
>>    I'm also not too hot on version bumping just for the sake of bumping.
>> Version bumps should be done when they're useful for someone, e.g.
>> because a feature or bugfix is added. If it's useful to you, then you'll
>> obviously test if it still works correctly.
>
> I understand this point of view, but on the other hand, it's not really
> nice to have packages that have very old versions. For "core" stuff
> that isn't necessarily very easy to bump (think Qt, Gtk, X.org and
> things like that), it's quite important that the core Buildroot
> community keeps that up to date, because this is difficult to do for
> newcomers, and this is what people will look at to see if Buildroot is
> well-maintained and active.

  Yes of course. The version detection idea is certainly useful. I just 
wanted to concur with Thomas DS that this shouldn't distract people from 
fixing autobuilder failures.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F