The discussion on reducing dependencies is great, but folks, we do need to produce a release soon, or else it'll be back to bad old days of one release a year (if you're lucky). Just saying... John.
On 8 June 2014 10:22, John Maddock <jz.maddock@googlemail.com> wrote:
The discussion on reducing dependencies is great, but folks, we do need to produce a release soon, or else it'll be back to bad old days of one release a year (if you're lucky). Just saying...
Marshall posted a possible schedule a few days ago, I put it on the calendar: http://www.boost.org/development/ It was proposed that master closes for breaking changes on the 16th, which is a bit short notice now.
Daniel James wrote:
On 8 June 2014 10:22, John Maddock <jz.maddock@googlemail.com> wrote:
The discussion on reducing dependencies is great, but folks, we do need to produce a release soon, or else it'll be back to bad old days of one release a year (if you're lucky). Just saying...
Marshall posted a possible schedule a few days ago, I put it on the calendar:
http://www.boost.org/development/
It was proposed that master closes for breaking changes on the 16th, which is a bit short notice now.
I, for one, have both seen Marshall's post and been keeping the release in mind. That said, the idea that modules need to freeze their master branch is a SVN relic. We are more evolved now; only the master branch of the superproject needs to freeze, and we can do that simply by stopping the script that updates the submodules on it.
On 8 June 2014 12:37, Peter Dimov <lists@pdimov.com> wrote:
That said, the idea that modules need to freeze their master branch is a SVN relic. We are more evolved now; only the master branch of the superproject needs to freeze, and we can do that simply by stopping the script that updates the submodules on it.
We still need a way to include non-breaking changes from submodules.
Daniel James wrote:
On 8 June 2014 12:37, Peter Dimov <lists@pdimov.com> wrote:
That said, the idea that modules need to freeze their master branch is a SVN relic. We are more evolved now; only the master branch of the superproject needs to freeze, and we can do that simply by stopping the script that updates the submodules on it.
We still need a way to include non-breaking changes from submodules.
Do you mean an automated way? If so, and if this requires modules to not update their master branches while a release is in progress... what was the point of the whole exercise?
On 8 June 2014 12:55, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
On 8 June 2014 12:37, Peter Dimov <lists@pdimov.com> wrote:
SVN relic. We are more evolved now; only the master branch of the > superproject needs to freeze, and we can do that simply by stopping the >
That said, the idea that modules need to freeze their master branch is a script that updates the submodules on it.
We still need a way to include non-breaking changes from submodules.
Do you mean an automated way?
In whatever way works.
If so, and if this requires modules to not update their master branches while a release is in progress... what was the point of the whole exercise?
We change the process in the future if we want, but right now, we've got more than enough on our plates.
On Sun, Jun 8, 2014 at 8:05 AM, Daniel James <dnljms@gmail.com> wrote:
Daniel James wrote:
On 8 June 2014 12:37, Peter Dimov <lists@pdimov.com> wrote:
That said, the idea that modules need to freeze their master branch
is a
SVN relic. We are more evolved now; only the master branch of the > superproject needs to freeze, and we can do that simply by stopping
On 8 June 2014 12:55, Peter Dimov <lists@pdimov.com> wrote: the >
script that updates the submodules on it.
We still need a way to include non-breaking changes from submodules.
Do you mean an automated way?
In whatever way works.
If so, and if this requires modules to not update their master branches while a release is in progress... what was the point of the whole exercise?
We change the process in the future if we want, but right now, we've got more than enough on our plates.
We don't have a viable release process in place yet, so we are going to have to make at least minimal changes. Straw man proposal: * On the 16th, (i.e. little more than a week from now) we turn off automatic sub-module master updates. * From that point until the release ships, a new library master release (with bug fixes only!) may be added manually to the Boost release by the release managers at their discretion. They have to be asked explicitly. * When the release ships, auto sub-module updates are turned back on. --Beman
We don't have a viable release process in place yet, so we are going to have to make at least minimal changes.
Straw man proposal:
* On the 16th, (i.e. little more than a week from now) we turn off automatic sub-module master updates. * From that point until the release ships, a new library master release (with bug fixes only!) may be added manually to the Boost release by the release managers at their discretion. They have to be asked explicitly. * When the release ships, auto sub-module updates are turned back on.
That sounds sensible to me, John.
On 8 Jun 2014 13:29, "John Maddock" <boost.regex@virgin.net> wrote:
We don't have a viable release process in place yet, so we are going to have to make at least minimal changes.
Straw man proposal:
* On the 16th, (i.e. little more than a week from now) we turn off automatic sub-module master updates. * From that point until the release ships, a new library master release (with bug fixes only!) may be added manually to the Boost release by the release managers at their discretion. They have to be asked explicitly. * When the release ships, auto sub-module updates are turned back on.
That sounds sensible to me, John.
Why do you need to stop the submodule updates for master? Surely the correct thing to do is create a branch that targets the release.
On Sun, Jun 8, 2014 at 9:09 AM, James Sharpe <mail@jsharpe.net> wrote:
On 8 Jun 2014 13:29, "John Maddock" <boost.regex@virgin.net> wrote:
We don't have a viable release process in place yet, so we are going to have to make at least minimal changes.
Straw man proposal:
* On the 16th, (i.e. little more than a week from now) we turn off automatic sub-module master updates. * From that point until the release ships, a new library master release (with bug fixes only!) may be added manually to the Boost release by the release managers at their discretion. They have to be asked explicitly. * When the release ships, auto sub-module updates are turned back on.
That sounds sensible to me, John.
Why do you need to stop the submodule updates for master? Surely the correct thing to do is create a branch that targets the release.
Interesting question. Unfortunately, we want to keep regression testing on what will become the release, and don't have an automatic way to switch the current master testers to a different branch. Or do we? Rene? --Beman
On Sun, Jun 8, 2014 at 10:36 AM, Beman Dawes <bdawes@acm.org> wrote:
On Sun, Jun 8, 2014 at 9:09 AM, James Sharpe <mail@jsharpe.net> wrote:
We don't have a viable release process in place yet, so we are going
to
have to make at least minimal changes.
Straw man proposal:
* On the 16th, (i.e. little more than a week from now) we turn off automatic sub-module master updates. * From that point until the release ships, a new library master release (with bug fixes only!) may be added manually to the Boost release by
On 8 Jun 2014 13:29, "John Maddock" <boost.regex@virgin.net> wrote: the
release managers at their discretion. They have to be asked explicitly. * When the release ships, auto sub-module updates are turned back on.
That sounds sensible to me, John.
Why do you need to stop the submodule updates for master? Surely the correct thing to do is create a branch that targets the release.
Interesting question. Unfortunately, we want to keep regression testing on what will become the release, and don't have an automatic way to switch the current master testers to a different branch.
Or do we? Rene?
It's actually easy for the testers.. As all they have to do is change the "--tag=master" option to something else. The "hard" one is spinning up more resources to process the output and post test results. Also of note is that we likely don't have enough testing resources to run an additional branch. We would have to have the current master testers switch to something else. And the master results would then stop updating. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Sun, Jun 8, 2014 at 4:39 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Jun 8, 2014 at 10:36 AM, Beman Dawes <bdawes@acm.org> wrote:
Interesting question. Unfortunately, we want to keep regression testing
what will become the release, and don't have an automatic way to switch
on the
current master testers to a different branch.
Or do we? Rene?
It's actually easy for the testers.. As all they have to do is change the "--tag=master" option to something else. The "hard" one is spinning up more resources to process the output and post test results. Also of note is that we likely don't have enough testing resources to run an additional branch. We would have to have the current master testers switch to something else. And the master results would then stop updating.
For the future (probably not this release), could we have the regression testers use a tag like "release-prep", which could point to different branches depending on what the release team needs to see? Most of the deveopment cycle, this would point to master, but as release branches are created, it could be updated in the script (or by some flag on a webpage, etc) to point to a different branch. This would mean that master isn't having any tests run on it during this period, but if we stop the submodule updates, we won't really be doing any tests on the current master either. Tom
On 8 June 2014 13:19, Beman Dawes <bdawes@acm.org> wrote:
We don't have a viable release process in place yet, so we are going to have to make at least minimal changes.
Straw man proposal:
* On the 16th, (i.e. little more than a week from now) we turn off automatic sub-module master updates. * From that point until the release ships, a new library master release (with bug fixes only!) may be added manually to the Boost release by the release managers at their discretion. They have to be asked explicitly. * When the release ships, auto sub-module updates are turned back on.
OK. Does every release manager have write access to the super project?
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 08 June 2014 10:23 To: boost@lists.boost.org Subject: [boost] Let's not forget the release
The discussion on reducing dependencies is great, but folks, we do need to produce a release soon, or else it'll be back to bad old days of one release a year (if you're lucky). Just saying...
Ditto - *please* let's get a post modular-boost release out before we start any serious refactoring. And no more delays - we were trying to make releases *more* frequent, but they are now very infrequent. I'm sure the process of making a release is going to be troublesome, just because it has changed. Let's get over that hurdle first (and many thanks to the hurdlers!) (I think the work on 'refactoring' to reduce dependencies is excellent BUT no-pain no-gain applies!) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
Paul A. Bristow wrote:
Ditto - *please* let's get a post modular-boost release out before we start any serious refactoring.
I did a double take when I read this, because it looks like you are recommending the opposite of what you're saying. But it's just that when you write "modular-boost", you're actually referring to non-modular-boost :).
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stephen Kelly Sent: 08 June 2014 13:03 To: boost@lists.boost.org Subject: Re: [boost] Let's not forget the release
Paul A. Bristow wrote:
Ditto - *please* let's get a post modular-boost release out before we start any serious refactoring.
I did a double take when I read this, because it looks like you are recommending the opposite of what you're saying.
But it's just that when you write "modular-boost", you're actually referring to non- modular-boost :).
I meant "modular-boost" - not "modular Boost" ;-) By "modular-boost" (note hyphen) I mean where are now after GITification and some improvements, but before Coreing. If nothing else, this should be a release that doesn't muck people about. The next release is bound to cause trouble, including, I fear real breaking changes - but will be worth it. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
participants (10)
-
Beman Dawes -
Daniel James -
James Sharpe -
John Maddock -
John Maddock -
Paul A. Bristow -
Peter Dimov -
Rene Rivera -
Stephen Kelly -
Tom Kent