Re: [Boost-users] [BoostCon07][testing] Session reminder.
on Thu May 03 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
Hi,
I do plan to attend this session. I've got some ideas on the subject. I pitched them while ago once. And I still believe that the synchronization is the root of all evils. The only real solution to break this deadloop is independent libraries versioning. This should resolve both out release and testing issues (which are closely connected IMO)
INDEPENDENT LIBRARY VERTIONING
I just want to point out that the BoostCon "Testing Boost" sprint is about our testing processes and infrastructure, not about the structure of Boost itself and its release process. I agree that the latter is an important topic and I hope we'll discuss it at BoostCon, but it's a much tougher issue (to form consensus on, and to solve) than is the topic of the sprint. In order to ensure that the sprint is successful, I strongly request that in Rene's session, we concentrate on the topic at hand. Thank you, -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
on Fri May 04 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
on Thu May 03 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
Hi,
I do plan to attend this session. I've got some ideas on the subject. I pitched them while ago once. And I still believe that the synchronization is the root of all evils. The only real solution to break this deadloop is independent libraries versioning. This should resolve both out release and testing issues (which are closely connected IMO)
INDEPENDENT LIBRARY VERTIONING
I just want to point out that the BoostCon "Testing Boost" sprint is about our testing processes and infrastructure, not about the structure of Boost itself and its release process. I agree that the latter is an important topic and I hope we'll discuss it at BoostCon, but it's a much tougher issue (to form consensus on, and to solve) than is the topic of the sprint. In order to ensure that the sprint is successful,
I strongly request that in Rene's session, we concentrate on the topic at hand.
Thank you,
Oh, and I request that those discussing the topic Gennadiy raises start a new thread or at minimum, change the subject line. Thanks again, -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87lkg4d5sj.fsf@valverde.peloton...
on Thu May 03 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
Hi,
I do plan to attend this session. I've got some ideas on the subject. I pitched them while ago once. And I still believe that the synchronization is the root of all evils. The only real solution to break this deadloop is independent libraries versioning. This should resolve both out release and testing issues (which are closely connected IMO)
INDEPENDENT LIBRARY VERTIONING
I just want to point out that the BoostCon "Testing Boost" sprint is about our testing processes and infrastructure, not about the structure of Boost itself and its release process. I agree that the latter is an important topic and I hope we'll discuss it at BoostCon, but it's a much tougher issue (to form consensus on, and to solve) than is the topic of the sprint. In order to ensure that the sprint is successful,
I strongly request that in Rene's session, we concentrate on the topic at hand.
While in general I agree, IMO discussing how we are going to test the libraries before deciding how the process is organized in general is like putting cart in front of a horse. Part of my proposition directly affect the way testing needs to be organized. Gennadiy.
on Fri May 04 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87lkg4d5sj.fsf@valverde.peloton...
I just want to point out that the BoostCon "Testing Boost" sprint is about our testing processes and infrastructure, not about the structure of Boost itself and its release process. I agree that the latter is an important topic and I hope we'll discuss it at BoostCon, but it's a much tougher issue (to form consensus on, and to solve) than is the topic of the sprint. In order to ensure that the sprint is successful,
I strongly request that in Rene's session, we concentrate on the topic at hand.
While in general I agree, IMO discussing how we are going to test the libraries before deciding how the process is organized in general is like putting cart in front of a horse. Part of my proposition directly affect the way testing needs to be organized.
Clearly. And a whole bunch of other things. It's a radical, sweeping change to how we do things that raises lots of knotty questions. This cart is already being driven by an ox, as it were, and we can't afford to buy a horse yet, nor can we easily agree that your horse is the best way to pull the cart. I hope we can upgrade the cart much sooner than we could agree on all that, and I know the process of doing so will stand us in good stead no matter how we decide to change the release process. There seems to be, more-or-less, a consensus on the list that in the near term, we'll be working with a variation of the plan Beman posted some time ago, which is already quite different from what we're doing now. We only have a short time to work on the testing problem in Aspen, and IMO much too little time there to agree on your plan. Again, In order to avoid derailing the sprint, I ask that we limit the scope of what we're considering there to the topic of the sprint. -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87hcqs9p9d.fsf@valverde.peloton...
on Fri May 04 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87lkg4d5sj.fsf@valverde.peloton...
I just want to point out that the BoostCon "Testing Boost" sprint is about our testing processes and infrastructure, not about the structure of Boost itself and its release process. I agree that the latter is an important topic and I hope we'll discuss it at BoostCon, but it's a much tougher issue (to form consensus on, and to solve) than is the topic of the sprint. In order to ensure that the sprint is successful,
I strongly request that in Rene's session, we concentrate on the topic at hand.
While in general I agree, IMO discussing how we are going to test the libraries before deciding how the process is organized in general is like putting cart in front of a horse. Part of my proposition directly affect the way testing needs to be organized.
Clearly. And a whole bunch of other things. It's a radical, sweeping
Not soo radical.
change to how we do things that raises lots of knotty questions.
It does. They can be resolved though IMO.
This cart is already being driven by an ox, as it were, and we can't afford to buy a horse yet, nor can we easily agree that your horse is the best way to pull the cart. I hope we can upgrade the cart much sooner than we could agree on all that, and I know the process of doing so will stand us in good stead no matter how we decide to change the release process.
I don't dare to assume my proposition is best possible. I just would like us to consider it.
There seems to be, more-or-less, a consensus on the list that in the near term, we'll be working with a variation of the plan Beman posted some time ago, which is already quite different from what we're doing now. We only have a short time to work on the testing problem in Aspen, and IMO much too little time there to agree on your plan.
Again, In order to avoid derailing the sprint, I ask that we limit the scope of what we're considering there to the topic of the sprint.
Again. I don't insist it to be discussed here and now. Though as I said in a long term this is the way to go IMO. The only reason I brought it up now is that it would affect the testing big time. Gennadiy
on Sat May 05 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87hcqs9p9d.fsf@valverde.peloton...
on Fri May 04 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
While in general I agree, IMO discussing how we are going to test the libraries before deciding how the process is organized in general is like putting cart in front of a horse. Part of my proposition directly affect the way testing needs to be organized.
Clearly. And a whole bunch of other things. It's a radical, sweeping
Not soo radical.
Maybe I should look at it again (when I find a few minutes). It seems as though your proposal has shifted a bit in response to feedback. Is there any chance you could throw the latest version up on the Boost Wiki (or, better, the new Boost Trac Wiki) so we can always look in the same place for the current state?
change to how we do things that raises lots of knotty questions.
It does. They can be resolved though IMO.
Perhaps they can; I just don't think we can do it in the next 10 days.
This cart is already being driven by an ox, as it were, and we can't afford to buy a horse yet, nor can we easily agree that your horse is the best way to pull the cart. I hope we can upgrade the cart much sooner than we could agree on all that, and I know the process of doing so will stand us in good stead no matter how we decide to change the release process.
I don't dare to assume my proposition is best possible. I just would like us to consider it.
As I mentioned already, I hope we will consider it (even at BoostCon), and maybe even account for it a little in the testing sprint. However, I also hope that we won't spend any time in the testing sprint discussing (or arguing about) how to restructure the release process. That means we have to agree on a working assumption about what the release process will be and I think we have to go with the "more-or-less consensus" that we already have.
There seems to be, more-or-less, a consensus on the list that in the near term, we'll be working with a variation of the plan Beman posted some time ago, which is already quite different from what we're doing now. We only have a short time to work on the testing problem in Aspen, and IMO much too little time there to agree on your plan.
Again, In order to avoid derailing the sprint, I ask that we limit the scope of what we're considering there to the topic of the sprint.
Again. I don't insist it to be discussed here and now.
Discussing it here and now is good. I'm worried about Monday, May 14 19:30 Mountain Daylight Time. :)
Though as I said in a long term this is the way to go IMO. The only reason I brought it up now is that it would affect the testing big time.
It's an important consideration. -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87irb777nl.fsf@valverde.peloton...
Maybe I should look at it again (when I find a few minutes). It seems as though your proposal has shifted a bit in response to feedback. Is there any chance you could throw the latest version up on the Boost Wiki (or, better, the new Boost Trac Wiki) so we can always look in the same place for the current state?
Do you mean this page: http://svn.boost.org/trac/boost/wiki? How do I add anything there? Gennadiy
on Sun May 06 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87irb777nl.fsf@valverde.peloton...
Maybe I should look at it again (when I find a few minutes). It seems as though your proposal has shifted a bit in response to feedback. Is there any chance you could throw the latest version up on the Boost Wiki (or, better, the new Boost Trac Wiki) so we can always look in the same place for the current state?
Do you mean this page: http://svn.boost.org/trac/boost/wiki?
How do I add anything there?
Send a request for subversion access to the mods, I think.
participants (2)
-
David Abrahams -
Gennadiy Rozental