[Buildroot] misc development news

[Buildroot] misc development news

[Peter Korsgaard]

Hi,

misc development news:

 - svn->git: Migration is starting to take shape. We have digged
   through svn history and found proper author/email info for all
   developers for the conversion, and the osuosl.org staff is setting
   up gitweb, commit notifications and various minor stuff for the
   conversion. Expect more info in ~1 weeks time.

- website: I recently bought buildroot.net and set up apache to
  respond to it, so you can now reach the buildroot website at the
  shorter http://buildroot.net address

- release: We're still on track for a 2009.05 release. Remember, the
  tree closes end April for new features when I'll cut the first
  release candidate. See
  http://lists.busybox.net/pipermail/buildroot/2009-February/025974.html
  for more details.

-- 
Bye, Peter Korsgaard

[Buildroot] misc development news

[Markus Heidelberg]

Peter Korsgaard, 27.02.2009:
> Hi,
> 
> misc development news:
> 
>  - svn->git: Migration is starting to take shape. We have digged
>    through svn history and found proper author/email info for all
>    developers for the conversion, and the osuosl.org staff is setting
>    up gitweb, commit notifications and various minor stuff for the
>    conversion. Expect more info in ~1 weeks time.

I'm looking forward to it.

> - website: I recently bought buildroot.net and set up apache to
>   respond to it, so you can now reach the buildroot website at the
>   shorter http://buildroot.net address

Until now I've always used buildroot.org, what's wrong with that?

Markus

[Buildroot] misc development news

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

 >> - svn->git: Migration is starting to take shape. We have digged

 Markus> I'm looking forward to it.

Me too ;)

 >> - website: I recently bought buildroot.net and set up apache to
 >> respond to it, so you can now reach the buildroot website at the
 >> shorter http://buildroot.net address

 Markus> Until now I've always used buildroot.org, what's wrong with that?

Well, it's not owned by any of the BR developers. It currently
redirects to buildroot.uclibc.org, but you never know if it will
continue to do so. According to whois it's owned by an Earl Levine,
that afaik never has been involved with buildroot/uclibc/busybox.

-- 
Bye, Peter Korsgaard

[Buildroot] misc development news

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

Hi,

 Peter>  - svn->git: Migration is starting to take shape. We have digged
 Peter>    through svn history and found proper author/email info for all
 Peter>    developers for the conversion, and the osuosl.org staff is setting
 Peter>    up gitweb, commit notifications and various minor stuff for the
 Peter>    conversion. Expect more info in ~1 weeks time.

Ok - Timing was "slightly" off, but the svn->git migration
uclibc.org-wide is almost completed. The repo can be browsed through
cgit at:

http://git.buildroot.net/buildroot/

It can be cloned anonymously using:

git clone git://git.buildroot.net/buildroot/ or
git clone http://git.buildroot.net/buildroot/ if you're behind a
firwall blocking git access.

Developers can also access the repo over ssh with:

git clone ssh://uclibc.org/var/lib/git/buildroot.git

But notice that you don't have write access, so you cannot push
changes directly. Instead push your changes to your own tree and send
pull requests to the list. You can add personal repos on uclibc.org by
storing them in ~/git/ and touching ~/git/<repo>/git-daemon-export-ok,
after which the hourly cronjob will pick them up and show them in
cgit.

I would like us to move to a setup similar to the kernel/uboot, where
all changes get posted to the list before they get committed to the
tree, and with package / sub-tree maintainers.

The repo was synched on the 17th, so it's missing the latest
changes. The svn repo will be turned read only once the final sync is
done, but more info about that later.

 Peter> - release: We're still on track for a 2009.05 release. Remember, the
 Peter>   tree closes end April for new features when I'll cut the first
 Peter>   release candidate. See
 Peter>   http://lists.busybox.net/pipermail/buildroot/2009-February/025974.html
 Peter>   for more details.

This is still the case. The aim is currently to close the tree for new
features and release 2009.05-rc1 sometime in the weekend 24-25th of
April.

-- 
Bye, Peter Korsgaard

[Buildroot] misc development news

[Thiago A. Corrêa]

Hi,

On Tue, Mar 31, 2009 at 6:23 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> git clone ssh://uclibc.org/var/lib/git/buildroot.git
>
> But notice that you don't have write access, so you cannot push
> changes directly. Instead push your changes to your own tree and send
> pull requests to the list. You can add personal repos on uclibc.org by
> storing them in ~/git/ and touching ~/git/<repo>/git-daemon-export-ok,
> after which the hourly cronjob will pick them up and show them in
> cgit.
>
> I would like us to move to a setup similar to the kernel/uboot, where
> all changes get posted to the list before they get committed to the
> tree, and with package / sub-tree maintainers.
>

This means that I currently have absolutely no idea how to commit.
Could you document this better or point us to a "Git for idiots (with
subversion background)"?

About maintainers... I don't see any easy way to divide that between
the developers. Any suggestions?

We usually all touch the packages folder quite often, subdividing that
also doesn't seem good to me as we sure use most of the same packages
in our builds and would like to fix stuff right away.
Dividing by platforms still leaves a big chunk out.

On top of all that, there is the who problem. Concentrating all pulls
on you kind of defeats the purpose of us even having commit access in
the first place.

Kind Regards,
   Thiago A. Correa

[Buildroot] misc development news

[Thomas Petazzoni]

Le Tue, 31 Mar 2009 23:23:03 +0200,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> But notice that you don't have write access, so you cannot push
> changes directly. Instead push your changes to your own tree and send
> pull requests to the list. You can add personal repos on uclibc.org by
> storing them in ~/git/ and touching ~/git/<repo>/git-daemon-export-ok,
> after which the hourly cronjob will pick them up and show them in
> cgit.

Ok.

> This is still the case. The aim is currently to close the tree for new
> features and release 2009.05-rc1 sometime in the weekend 24-25th of
> April.

What about bug-fix versions of the latest stable release ? Do we plan
to release things such as 2009.02.1, 2009.02.2, etc. ? When trying
to use 2009.02 for a demo today, I faced several issues that have been
fixed since then. But maybe it's too much burden for the moment ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] misc development news

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> What about bug-fix versions of the latest stable release ? Do we plan
 Thomas> to release things such as 2009.02.1, 2009.02.2, etc. ? When trying
 Thomas> to use 2009.02 for a demo today, I faced several issues that have been
 Thomas> fixed since then. But maybe it's too much burden for the moment ?

I'm not against doing that, but I'm afraid I don't have the bandwidth
to do it alone. If people want to help point out commits we should
backport, then we could do it.

This should be limited to the absolutely critical stuff ofcourse.

-- 
Bye, Peter Korsgaard

[Buildroot] misc development news

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi Thiago,

Sorry for the slow response - I went on holiday before answering and
then forgot about the mail ..

 >> I would like us to move to a setup similar to the kernel/uboot, where
 >> all changes get posted to the list before they get committed to the
 >> tree, and with package / sub-tree maintainers.
 >> 

 Thiago> This means that I currently have absolutely no idea how to
 Thiago> commit.  Could you document this better or point us to a "Git
 Thiago> for idiots (with subversion background)"?

Don't worry, it's not that hard ;)

The official documentation is quite good. Take a look at
http://git-scm.com/documentation and
http://git-scm.com/course/svn.html in particular.

For contributing you basically have 2 options: Either simply send
patches to the list (see man git-format-patch and man git-send-email),
or setup a public git tree (on uclibc.org, your own machine or one of
the many git hosting sites like github, repo.or.cz, ..) and send a
pull request to the list.

In fact I would like us to move to a workflow where all changes are
first posted to the list before committing to the official tree,
similar to how it's handled in the Linux kernel, U-Boot,  ..

 Thiago> About maintainers... I don't see any easy way to divide that
 Thiago> between the developers. Any suggestions?

I agree that it isn't that clear cut, but I could certainly imagine
maintainers for specific archs and groups of packages like the X
stack, gtk, qt, java stuff and so on.

 Thiago> We usually all touch the packages folder quite often,
 Thiago> subdividing that also doesn't seem good to me as we sure use
 Thiago> most of the same packages in our builds and would like to fix
 Thiago> stuff right away.  Dividing by platforms still leaves a big
 Thiago> chunk out.

We currently have more than 600 packages - I for sure only use a very
limited subset on a regular basis.

 Thiago> On top of all that, there is the who problem. Concentrating
 Thiago> all pulls on you kind of defeats the purpose of us even
 Thiago> having commit access in the first place.

The wonderful part of distributed version control is that you aren't
blocked if I dissapear for a few days. The only "special" thing about
my tree is that I do releases from it.

We had various problems in the past with the svn "ghetto" style of
development where all developers could commit as they pleased with
very little review. The git setup works for projects much larger than
ours, so I think it's atleast worth a try.

-- 
Bye, Peter Korsgaard

[Buildroot] misc development news

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

Hi,

 Peter> - svn->git: Migration is starting to take shape. We have digged
 Peter> through svn history and found proper author/email info for all
 Peter> developers for the conversion, and the osuosl.org staff is setting
 Peter> up gitweb, commit notifications and various minor stuff for the
 Peter> conversion. Expect more info in ~1 weeks time.

 Peter> Ok - Timing was "slightly" off, but the svn->git migration
 Peter> uclibc.org-wide is almost completed. The repo can be browsed through
 Peter> cgit at:

..

 Peter> The repo was synched on the 17th, so it's missing the latest
 Peter> changes. The svn repo will be turned read only once the final sync is
 Peter> done, but more info about that later.

From the osuosl.org staff:

Hi, if you are satisfied with the test git setup I am ready to perform
the final conversion.  I expect about an hour between freezing the SVN
repo and having the git repos ready if everything goes according to
plan.  Would Thursday at 10AM be an acceptable time?

-- 
Bye, Peter Korsgaard

[Buildroot] misc development news

[Thiago A. Corrêa]

Hi Peter,

2009/4/28 Peter Korsgaard <jacmet@uclibc.org>:
>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>
> Hi Thiago,
>
> Sorry for the slow response - I went on holiday before answering and
> then forgot about the mail ..

It's ok. I had hopes that you had thought that git was too much
trouble for what it's worth. Oh well. :(

>
> ?Thiago> This means that I currently have absolutely no idea how to
> ?Thiago> commit. ?Could you document this better or point us to a "Git
> ?Thiago> for idiots (with subversion background)"?
>
> Don't worry, it's not that hard ;)

I usually say that about C++ programming but somehow ppl usually don't
seem to fully agree :P

> For contributing you basically have 2 options: Either simply send
> patches to the list (see man git-format-patch and man git-send-email),
> or setup a public git tree (on uclibc.org, your own machine or one of
> the many git hosting sites like github, repo.or.cz, ..) and send a
> pull request to the list.

That's the part I would like to know more. How exactly do you setup
the git repository at uclibc.org?

> In fact I would like us to move to a workflow where all changes are
> first posted to the list before committing to the official tree,
> similar to how it's handled in the Linux kernel, U-Boot, ?..

I don't see that working. It does for the linux kernel because of the
size of it's contributor base, we are greatly under powered for this
scheme. Patches would just get a big backlog for you to handle and we
would be unable to help.
I think the current commit first review later works best in our case.
We don't quite have enough ppl reviewing changes and reverting a patch
has been uncommon, yet, it's not that hard when necessary.

Also, I don't really like the individual trees concept. If someone
breaks the avr32 build fixing the ppc, I only get to figure this out
possibly at release. Integration testing, which isn't really good
right now, will get worst IMHO.

> ?Thiago> About maintainers... I don't see any easy way to divide that
> ?Thiago> between the developers. Any suggestions?
>
> I agree that it isn't that clear cut, but I could certainly imagine
> maintainers for specific archs and groups of packages like the X
> stack, gtk, qt, java stuff and so on.

Perhaps this should be sorted out before using changing the repository.

> ?Thiago> We usually all touch the packages folder quite often,
> ?Thiago> subdividing that also doesn't seem good to me as we sure use
> ?Thiago> most of the same packages in our builds and would like to fix
> ?Thiago> stuff right away. ?Dividing by platforms still leaves a big
> ?Thiago> chunk out.
>
> We currently have more than 600 packages - I for sure only use a very
> limited subset on a regular basis.

True, but sometimes when there are trivial changes needed, having to
figure out what maintainer to bother or actually having to do more
than start vi, test then svn commit is a big step back.


> ?Thiago> On top of all that, there is the who problem. Concentrating
> ?Thiago> all pulls on you kind of defeats the purpose of us even
> ?Thiago> having commit access in the first place.
>
> The wonderful part of distributed version control is that you aren't
> blocked if I dissapear for a few days. The only "special" thing about
> my tree is that I do releases from it.

Not quite. Your tree would be the integration tree. Having a separate
tree for me is of little value as I don't create that big amount of
patches myself, but I do test others changes often since I do svn
updates often. With this setup I would have to monitor the mailling
list all the time for pulls. Likewise, my changes get less testing
untill you decide to merge.

> We had various problems in the past with the svn "ghetto" style of
> development where all developers could commit as they pleased with
> very little review. The git setup works for projects much larger than
> ours, so I think it's atleast worth a try.

I think the problem was with people management and how we did (or
actually didn't do) conflict solving. In the past we didn't have a
maintainer to help solving the conflicts.
We are not going to really solve it with a different tool.

Kind Regards,
    Thiago A. Correa

[Buildroot] misc development news

[Markus Heidelberg]

Thiago A. Corr?a, 29.04.2009:
> Hi Peter,
> 
> 2009/4/28 Peter Korsgaard <jacmet@uclibc.org>:
> 
> > In fact I would like us to move to a workflow where all changes are
> > first posted to the list before committing to the official tree,
> > similar to how it's handled in the Linux kernel, U-Boot, ?..
> 
> I don't see that working. It does for the linux kernel because of the
> size of it's contributor base, we are greatly under powered for this
> scheme. Patches would just get a big backlog for you to handle and we
> would be unable to help.
> I think the current commit first review later works best in our case.
> We don't quite have enough ppl reviewing changes and reverting a patch
> has been uncommon, yet, it's not that hard when necessary.

Peter seems to review many commits and fixes them or asks the committers
to fix them. So maybe the work isn't really less nowadays, but I'm not
sure.

> > We had various problems in the past with the svn "ghetto" style of
> > development where all developers could commit as they pleased with
> > very little review. The git setup works for projects much larger than
> > ours, so I think it's atleast worth a try.
> 
> I think the problem was with people management and how we did (or
> actually didn't do) conflict solving. In the past we didn't have a
> maintainer to help solving the conflicts.
> We are not going to really solve it with a different tool.

The problems don't have to be solved, because they don't exist any more,
at least not in this amount.

Markus

[Buildroot] misc development news

[Thiago A. Corrêa]

On Wed, Apr 29, 2009 at 6:00 PM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> Thiago A. Corr?a, 29.04.2009:
>> 2009/4/28 Peter Korsgaard <jacmet@uclibc.org>:
>>
>> > In fact I would like us to move to a workflow where all changes are
>> > first posted to the list before committing to the official tree,
>> > similar to how it's handled in the Linux kernel, U-Boot, ?..
>>
>> I don't see that working. It does for the linux kernel because of the
>> size of it's contributor base, we are greatly under powered for this
>> scheme. Patches would just get a big backlog for you to handle and we
>> would be unable to help.
>> I think the current commit first review later works best in our case.
>> We don't quite have enough ppl reviewing changes and reverting a patch
>> has been uncommon, yet, it's not that hard when necessary.
>
> Peter seems to review many commits and fixes them or asks the committers
> to fix them. So maybe the work isn't really less nowadays, but I'm not
> sure.
>

Indeed unfortunally I don't offer as much help as I would like to, but
at least I don't get in the way *smile*
Imagine that on top of that, he would have to commit your patches, my
patches, etc.
It does look like it is work to do the same job.

If we don't sort out how we are going to work, this move could just
send ppl away, frustrated because we can't get things done.
I for one am still clueless on how should I continue to contribute,
and yet I'm afraid that I will have to keep track of several different
trees, on top of the 2 I already have (My private development +
upstream buildroot).

[Buildroot] misc development news

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi,

 >> Sorry for the slow response - I went on holiday before answering
 >> and then forgot about the mail ..

 Thiago> It's ok. I had hopes that you had thought that git was too
 Thiago> much trouble for what it's worth. Oh well. :(

Heh ;)

Git is nice, trust me. It take a little while to get used to, but it
is very neat.

Notice that the git migration is uclibc wide
(E.G. uclibc/busybox/buildroot/uclibc++).

 >> Don't worry, it's not that hard ;)

 Thiago> I usually say that about C++ programming but somehow ppl
 Thiago> usually don't seem to fully agree :P

If you can comprehend C++ then git shouldn't be a problem either :P

 >> For contributing you basically have 2 options: Either simply send
 >> patches to the list (see man git-format-patch and man git-send-email),
 >> or setup a public git tree (on uclibc.org, your own machine or one of
 >> the many git hosting sites like github, repo.or.cz, ..) and send a
 >> pull request to the list.

 Thiago> That's the part I would like to know more. How exactly do you setup
 Thiago> the git repository at uclibc.org?

See my mail of last month:

http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html

If you put git repos in your ~/git/ dir and make sure you have a
git-daemon-export-ok in them, then they can be accessed through git://
and cgit just like the "official" repos.

See the git documentation (http://git-scm.com/documentation) for info
about creating (cloning) repos.

 >> In fact I would like us to move to a workflow where all changes are
 >> first posted to the list before committing to the official tree,
 >> similar to how it's handled in the Linux kernel, U-Boot, ?..

 Thiago> I don't see that working. It does for the linux kernel
 Thiago> because of the size of it's contributor base, we are greatly
 Thiago> under powered for this scheme. Patches would just get a big
 Thiago> backlog for you to handle and we would be unable to help.  I
 Thiago> think the current commit first review later works best in our
 Thiago> case.  We don't quite have enough ppl reviewing changes and
 Thiago> reverting a patch has been uncommon, yet, it's not that hard
 Thiago> when necessary.

That's almost the situation today as well:

git shortlog -n -s --since='feb 12'
   333  jacmet
    15  correa
     8  tpetazzoni
     2  hamish
     2  wberrier
     1  austinf

In other words, 92% of all commits since the last release has gone
through me.

This doesn't mean that it has to be doing all the work. If you could
help review patches and ack/nack, and then send me a pull request of
everything you think is good then that would be a big help.

 Thiago> Also, I don't really like the individual trees concept. If
 Thiago> someone breaks the avr32 build fixing the ppc, I only get to
 Thiago> figure this out possibly at release. Integration testing,
 Thiago> which isn't really good right now, will get worst IMHO.

I'm certainly open to discuss the details - Do you have any suggestion
how we could do this better?

 >> I agree that it isn't that clear cut, but I could certainly imagine
 >> maintainers for specific archs and groups of packages like the X
 >> stack, gtk, qt, java stuff and so on.

 Thiago> Perhaps this should be sorted out before using changing the
 Thiago> repository.

Hard to do as this is done uclibc wise and has been pending for a long
time. There's imho no real problem with refining our work flow as we
go (we're entering release freeze this weekend anyway).

 >> We currently have more than 600 packages - I for sure only use a very
 >> limited subset on a regular basis.

 Thiago> True, but sometimes when there are trivial changes needed,
 Thiago> having to figure out what maintainer to bother or actually
 Thiago> having to do more than start vi, test then svn commit is a
 Thiago> big step back.

The fact that you can commit locally means that you can fix the
problem locally just as easily, it's just the path to the "official"
tree that takes a bit longer.

 >> ?Thiago> On top of all that, there is the who problem. Concentrating
 >> ?Thiago> all pulls on you kind of defeats the purpose of us even
 >> ?Thiago> having commit access in the first place.
 >> 
 >> The wonderful part of distributed version control is that you aren't
 >> blocked if I dissapear for a few days. The only "special" thing about
 >> my tree is that I do releases from it.

 Thiago> Not quite. Your tree would be the integration tree. Having a
 Thiago> separate tree for me is of little value as I don't create
 Thiago> that big amount of patches myself, but I do test others
 Thiago> changes often since I do svn updates often. With this setup I
 Thiago> would have to monitor the mailling list all the time for
 Thiago> pulls. Likewise, my changes get less testing untill you
 Thiago> decide to merge.

A seperate tree still means that you can easily test out changes
(yours or from someone else) before they get integrated into the
official tree.

 >> We had various problems in the past with the svn "ghetto" style of
 >> development where all developers could commit as they pleased with
 >> very little review. The git setup works for projects much larger than
 >> ours, so I think it's atleast worth a try.

 Thiago> I think the problem was with people management and how we did
 Thiago> (or actually didn't do) conflict solving. In the past we
 Thiago> didn't have a maintainer to help solving the conflicts.  We
 Thiago> are not going to really solve it with a different tool.

I partly agree. It's a combined people/technical problem.

-- 
Bye, Peter Korsgaard

[Buildroot] misc development news

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

Hi,

 Markus> Peter seems to review many commits and fixes them or asks the
 Markus> committers to fix them. So maybe the work isn't really less
 Markus> nowadays, but I'm not sure.

I also don't think it will change much. As I mentioned in my previous
mail, 92% of all commits since 2009.02 has gone through me.

 Markus> The problems don't have to be solved, because they don't
 Markus> exist any more, at least not in this amount.

No, not at the moment, but it could happen again. There's also the big
issue about quality of patches, I certainly think more review would be
good.

-- 
Bye, Peter Korsgaard

[Buildroot] misc development news

[Markus Heidelberg]

Thiago A. Corr?a, 29.04.2009:
> On Wed, Apr 29, 2009 at 6:00 PM, Markus Heidelberg
> > Peter seems to review many commits and fixes them or asks the committers
> > to fix them. So maybe the work isn't really less nowadays, but I'm not
> > sure.
> >
> 
> Indeed unfortunally I don't offer as much help as I would like to, but
> at least I don't get in the way *smile*
> Imagine that on top of that, he would have to commit your patches, my
> patches, etc.

We can make his life easier with sending proper patch mails. Applying
them and committing will then be a rather automatic procedure.

> If we don't sort out how we are going to work, this move could just
> send ppl away, frustrated because we can't get things done.

The workflow and the problems before had sent people away, at least of
Bernhard I'm aware.

> I for one am still clueless on how should I continue to contribute,
> and yet I'm afraid that I will have to keep track of several different
> trees, on top of the 2 I already have (My private development +
> upstream buildroot).

Which extra trees do you think you need because of the changed workflow?
On the other hand, this is exactly which you can get much easier with
git in contrast to svn. Just create local branches as much as you need.
The data exchange between your private branch and the branch for your
changes that are meant for upstream also is pretty comfortable.

Markus

[Buildroot] misc development news

[Markus Heidelberg]

Peter Korsgaard, 30.04.2009:
> >>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:
> 
>  Markus> The problems don't have to be solved, because they don't
>  Markus> exist any more, at least not in this amount.
> 
> No, not at the moment, but it could happen again. There's also the big
> issue about quality of patches, I certainly think more review would be
> good.

Oh, I meant the problems don't exist in a workflow, where only one
person has commit access and review is done before it. I should have
used "would" to make it clear.

Markus

[Buildroot] misc development news

[Frank Hoeflich]

Thomas:

    It's very staunch of Peter to be willing to discuss this, but it generally defeats the purpose of the three-month train development model.  Fixes to releases are supposed to be integrated and released so quickly in this case that you don't need dot-dot releases.  Once we have a few canned releases from which to choose, I wouldn't expect this to be a problem at all.  Since we have only the 2009.02 right now, I suppose a one-off could be justifiable if you expect to be giving multiple demos with it in the next month.  My $.02

    BTW I think you are demoing here at ELC - so welcome to San Francisco!

--Frank

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
>Hi,
>
>Thomas> What about bug-fix versions of the latest stable release ? Do we plan
>Thomas> to release things such as 2009.02.1, 2009.02.2, etc. ? When trying
>Thomas> to use 2009.02 for a demo today, I faced several issues that have been
>Thomas> fixed since then. But maybe it's too much burden for the moment ?
>
>I'm not against doing that, but I'm afraid I don't have the bandwidth
>to do it alone. If people want to help point out commits we should
>backport, then we could do it.
>
>This should be limited to the absolutely critical stuff ofcourse.
>
>-- 
>Bye, Peter Korsgaard>


      

[Buildroot] misc development news

[Darcy Watkins]

Hello,

Perhaps an alternative to releasing bugfix versions would be bugfix
update patches.  Apply the latest update after extracting the 2009.02
release tarball.

2009.02.update.01.patch
2009.02.update.02.patch
...etc.

And for the benefit of those who would apply updates as they go,
incrementals updates would be helpful too - such as.

2009.02.inc-update.01-02.patch
2009.02.inc-update.02-03.patch
...etc.

And I agree, it should be limited to critical fixes, security issues,
etc.

Regards,

Darcy