A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A... Comments welcomed! The proposed process refinements are meant to complement the parallel ongoing efforts to improve our tools, but don't depend on any tool improvements. Thus we can get started as soon as we reach sufficient consensus. That said, I think tools are very important, and hope we can rapidly make improvements in both process and tools. --Beman
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
Overall this sounds good. The one thing I'm not sure about is the introduced dichotomy between core and non-core libraries. Why not simply talk about prerequisite libraries as those libraries others depend on ? This reuses the technical term 'prerequisite', and doesn't overload the meaning of 'core'. In other words, whether or not a library belongs into the 'core' (whatever that is), and whether it is a prerequisite for another library, are two distinct and orthogonal questions. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
Overall this sounds good. The one thing I'm not sure about is the introduced dichotomy between core and non-core libraries. Why not simply talk about prerequisite libraries as those libraries others depend on ? This reuses the technical term 'prerequisite', and doesn't overload the meaning of 'core'. In other words, whether or not a library belongs into the 'core' (whatever that is), and whether it is a prerequisite for another library, are two distinct and orthogonal questions.
Ah! I wasn't happy with 'core' either, but failed to come up with anything better. "Prerequisite" is definitely better. Changed. Thanks, --Beman
on Tue Aug 07 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Stefan Seefeld wrote:
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
Overall this sounds good. The one thing I'm not sure about is the introduced dichotomy between core and non-core libraries. Why not simply talk about prerequisite libraries as those libraries others depend on ? This reuses the technical term 'prerequisite', and doesn't overload the meaning of 'core'. In other words, whether or not a library belongs into the 'core' (whatever that is), and whether it is a prerequisite for another library, are two distinct and orthogonal questions.
Ah! I wasn't happy with 'core' either, but failed to come up with anything better. "Prerequisite" is definitely better.
I would use "dependent" and "dependency." -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
Ah! I wasn't happy with 'core' either, but failed to come up with anything better. "Prerequisite" is definitely better.
I would use "dependent" and "dependency."
But the meaning of 'dependent' is the opposite from 'prerequisite', isn't it ? If A depends on B, B is a prerequisite library. 'prerequisite' is an adjective, while 'dependency' isn't. (How foolish am I to argue with *you* about English ? ;-) ) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
David Abrahams wrote:
on Tue Aug 07 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Stefan Seefeld wrote:
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed! Overall this sounds good. The one thing I'm not sure about is the introduced dichotomy between core and non-core libraries. Why not simply talk about prerequisite libraries as those libraries others depend on ? This reuses the technical term 'prerequisite', and doesn't overload the meaning of 'core'. In other words, whether or not a library belongs into the 'core' (whatever that is), and whether it is a prerequisite for another library, are two distinct and orthogonal questions. Ah! I wasn't happy with 'core' either, but failed to come up with anything better. "Prerequisite" is definitely better.
I would use "dependent" and "dependency."
The trouble with those is that they describe a library that depends on another. We need a word to describe the library being depended upon. --Beman
Beman Dawes wrote:
David Abrahams wrote:
on Tue Aug 07 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Ah! I wasn't happy with 'core' either, but failed to come up with anything better. "Prerequisite" is definitely better.
I would use "dependent" and "dependency."
The trouble with those is that they describe a library that depends on another. We need a word to describe the library being depended upon.
I've used 'dependee', but I'm not sure if it's correct English. (IMHO it makes sufficient sense when discussing dependencies back and forth. :) /Marcus
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcus Lindblom Sent: 07 August 2007 16:43 To: boost@lists.boost.org Subject: Re: [boost] Development and Release Practices
I would use "dependent" and "dependency."
The trouble with those is that they describe a library that depends on another. We need a word to describe the library being depended upon.
I've used 'dependee', but I'm not sure if it's correct English.
No according to me - and as I'm really English English, I should know ;¬)) I don't think there is an existing word, surprisingly. I am the provider for my dependents, but that too isn't quite the right word? It doesn't quite imply that I really am depended on? But how about "dependent" for the file that depends on another and "depended" for the file that is depended upon The 'upon' or 'on' is implied of course "depended-on" would be clearer but shorter? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul A Bristow Sent: Tuesday, August 07, 2007 2:01 PM To: boost@lists.boost.org Subject: Re: [boost] Development and Release Practices
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcus Lindblom Sent: 07 August 2007 16:43 To: boost@lists.boost.org Subject: Re: [boost] Development and Release Practices
I would use "dependent" and "dependency."
The trouble with those is that they describe a library that depends on another. We need a word to describe the library being depended upon.
I've used 'dependee', but I'm not sure if it's correct English.
No according to me - and as I'm really English English, I should know ;¬))
I don't think there is an existing word, surprisingly.
I am the provider for my dependents, but that too isn't quite the right word? It doesn't quite imply that I really am depended on?
But how about "dependent" for the file that depends on another and
"depended" for the file that is depended upon
The 'upon' or 'on' is implied of course
"depended-on" would be clearer but shorter?
You could also use the word 'requires'. Library X requires library Y. Says the right thing. joe
Paul A Bristow wrote:
I've used 'dependee', but I'm not sure if it's correct English.
No according to me - and as I'm really English English, I should know ;¬))
I don't think there is an existing word, surprisingly.
I am the provider for my dependents, but that too isn't quite the right word? It doesn't quite imply that I really am depended on?
I still fail to see the problem. What is wrong with 'prerequisite' ? The entry in http://mw1.merriam-webster.com/dictionary/prerequisite makes it look quite suitable. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Wed Aug 08 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
I've used 'dependee', but I'm not sure if it's correct English.
No according to me - and as I'm really English English, I should know ;¬))
I don't think there is an existing word, surprisingly.
I am the provider for my dependents, but that too isn't quite the right word? It doesn't quite imply that I really am depended on?
I still fail to see the problem. What is wrong with 'prerequisite' ? The entry in http://mw1.merriam-webster.com/dictionary/prerequisite makes it look quite suitable.
There's a subtle temporal aspect ("pre") that I don't think we want to communicate. Actually I don't like either "prerequisite" or "dependency" all that much, because both imply that the prerequisite/dependency library isn't useful on its own ("it's just a prerequisite for the rest of Boost"). I think, unless we're talking explicitly about a relationship between two libraries, I prefer "core" or "base" or something simple like Beman chose initially, which distinguishes the libraries' role without implying any relationship to the other libraries. We can still use that relationship as a criterion for choosing core libraries. backpedaling-ly y'rs, dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
on Tue Aug 07 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
on Tue Aug 07 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Stefan Seefeld wrote:
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed! Overall this sounds good. The one thing I'm not sure about is the introduced dichotomy between core and non-core libraries. Why not simply talk about prerequisite libraries as those libraries others depend on ? This reuses the technical term 'prerequisite', and doesn't overload the meaning of 'core'. In other words, whether or not a library belongs into the 'core' (whatever that is), and whether it is a prerequisite for another library, are two distinct and orthogonal questions. Ah! I wasn't happy with 'core' either, but failed to come up with anything better. "Prerequisite" is definitely better.
I would use "dependent" and "dependency."
The trouble with those is that they describe a library that depends on another.
No, a dependent depends upon a dependency. This is the terminology used in build systems. As confusable as it may be, it makes little sense to invent new terms IMO. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
No, a dependent depends upon a dependency. This is the terminology used in build systems. As confusable as it may be, it makes little sense to invent new terms IMO.
http://www.gnu.org/software/autoconf/manual/make/Prerequisite-Types.html Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
Overall this sounds good. The one thing I'm not sure about is the introduced dichotomy between core and non-core libraries. Why not simply talk about prerequisite libraries as those libraries others depend on ? This reuses the technical term 'prerequisite', and doesn't overload the meaning of 'core'. In other words, whether or not a library belongs into the 'core' (whatever that is), and whether it is a prerequisite for another library, are two distinct and orthogonal questions.
One problem I can see is that just about everything is a prerequisite of the serialization library. Not only does it depend on a lot of other classes, but changes to the other classes that would not break most clients will break the serialization code: for example if a class adds a new data member and a constructor with an extra parameter to initialize it. Joe Gottman
Joe Gottman wrote:
changes to the other classes that would not break most clients will break the serialization code: for example if a class adds a new data member and a constructor with an extra parameter to initialize it.
This is not a problem. The serialization library will no have any new serialization implementations. In the future, all serialization implementations have been part of the library which defines the type. It has been this way in the begining for data-time, multi-indexe, ranges? and I'm sure a number of others. So it would seem that I'm only stuck with the stl and a couple of others like shared_ptr and variant. But its not even that bad. STL isn't expected to change, and Matthias Troyer has continued necessary refinements for collections so that leaves just a couple to keep me honest. Its true that serialization uses a lot of boost for its implementation. This is a "good thing (tm)" as the serialization library is larger than I'd like anyway. But if someone breaks a published interface that I use, well, I'd get upset and we'll have to sort it out the old fashioned way. But this brings up a couple of very interesting examples. a) spirit - No way did I want to deal with parsing XML. A big pain to do and worse to maintain. Spirit save my life here. But it is much more than that. Joel has kept faith in leaving the original library around so that serialization still works with older platforms like borland 5.51 and msvc 6.0 and who knows what else. I haven't had to tweak the xml parsing for a couple of years (except to fix one or the other mistake in grammer specification. I can't emphasise how important this is. It means I can hand off a significant part of the implemenation the library to another library and forget it and move on. Contrary to what it might appear - serialization is not my life and thought I like to keep my hand in from time to time, I don't want to have to constantly go back and add stuff in that someone doesn't support anymore. Making something that people are really going to depend on in a real product requires this professionalism and commitment that frankly most people don't really appreciates. So, Joel, if you ever think of getting a real job, feel free to ask me for a letter of recommendation. b) The other example is the boost test library. I read the documentation and I thought it was wonderful. I had seen unit testing promoted before but really it was just lip service. Following the instructions in the manual and examples let me write 50 tests for the serialization library. My needs were well served by the header only version and I was satisfied. But, then the test system started to break with older compilers. This was due to enhancements in the library that older compilers couldn't support. I complained, but the response I got was that I wasn't spending my time well supporting the older compilers so basically, I was given the choice of elminating dependence on Boost Test or throwing away serialization library support for older compilers. I confess I resented having to make such a choice - but I had no choice but to choose. And in a nutshell, this is what will happen and what must happen when a library's published interface changes. It's happened in the past and will happen in the future. Its not really a function of the test/release policies - its just is. Improved test/lrelease policies can detect this in a timely and orderly manner - but the resolution willl be as it always has been. Robert Ramey
on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Joe Gottman wrote:
changes to the other classes that would not break most clients will break the serialization code: for example if a class adds a new data member and a constructor with an extra parameter to initialize it.
This is not a problem.
The serialization library will no have any new serialization implementations. In the future, all serialization implementations have been part of the library which defines the type. It has been this way in the begining for data-time, multi-indexe, ranges? and I'm sure a number of others. So it would seem that I'm only stuck with the stl and a couple of others like shared_ptr and variant.
But its not even that bad. STL isn't expected to change, and Matthias Troyer has continued necessary refinements for collections so that leaves just a couple to keep me honest.
Then, as with the Python library, we have the opposite problem: most other libraries are dependent upon Serialization. In reality, python bindings and serialization code are separable and optional parts, and we ought to have some way to treat them as such from the point of view of the testing and release processes. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Then, as with the Python library, we have the opposite problem: most other libraries are dependent upon Serialization.
Hmm "we"? I would say that if that is a problem, it would be the problem of the library maintainer and he can/will decide how much he wants to depend on another library. I don't see the serialization library any different than any other library in this regard. Of course if the library maintainer wants to make serialization of his types an optional part or of his library he's free to do so using a command line arguement to bjam or whatever. But still - its up to him - its not a boost problem.
In reality, python bindings and serialization code are separable and optional parts, and we ought to have some way to treat them as such from the point of view of the testing and release processes.
Most of the other libraries which contain serialization code have a separate (and optional) header for it (similar to the headers in the serialization library for stl collections) so I don't think there is a lot to be concerned about here. Robert Ramey
on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Then, as with the Python library, we have the opposite problem: most other libraries are dependent upon Serialization.
Hmm "we"?
Umm, yes. Like it or not, we're all in this together. Dependencies can cause problems for the maintainers at both ends of the relation.
I would say that if that is a problem, it would be the problem of the library maintainer and he can/will decide how much he wants to depend on another library. I don't see the serialization library any different than any other library in this regard.
It's very different, because it's not an implementation detail. If I write a library of containers, nobody will come to me complaining that "your library doesn't support type_traits." They are likely to complain that I don't support Boost.Serialization (or Boost.Python).
Of course if the library maintainer wants to make serialization of his types an optional part or of his library he's free to do so using a command line arguement to bjam or whatever. But still - its up to him -
Of course it's up to him. Who implied otherwise?
its not a boost problem.
When it becomes an issue that many library authors have to deal with, it becomes a Boost problem. If everybody deals with it in a unique way, we will have more problems than if we have a coherent pattern to follow that minimizes release and testing problems.
In reality, python bindings and serialization code are separable and optional parts, and we ought to have some way to treat them as such from the point of view of the testing and release processes.
Most of the other libraries which contain serialization code have a separate (and optional) header for it (similar to the headers in the serialization library for stl collections) so I don't think there is a lot to be concerned about here.
If serialization and python become "prerequisite libraries" just because other libraries "depend" on them, that's a big problem. These problems are not insurmountable, but they deserves attention. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
Looks sensible to me, once we get testing started on the trunk again, and a release manager appointed we should be able to put this into action right away, and then gradually refine it as new tools become available (test on demand for a branch etc). John.
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
Simple question, regarding this: Developers can ensure a stable development environment by checking out //svn.boost.org/svn/boost/release as their working copy, and then switching only the library they are working with to //svn.boost.org/svn/boost/trunk or a library specific development branch. AFAIK subversion doesn't allow switching individual files, only directories. How would one switch for example "boost/regex.hpp"? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
Simple question, regarding this:
Developers can ensure a stable development environment by checking out //svn.boost.org/svn/boost/release as their working copy, and then switching only the library they are working with to //svn.boost.org/svn/boost/trunk or a library specific development branch.
AFAIK subversion doesn't allow switching individual files, only directories. How would one switch for example "boost/regex.hpp"?
IIRC you can switch individual files: svn switch \ https://svn.boost.org/svn/boost/branches/whatever/boost/regex.hpp \ boost/regex.hpp Unrelated side note; what's up with the complicated path? Why don't we simply have https://svn.boost.org/trunk? -- Daniel Wallin Boost Consulting www.boost-consulting.com
Daniel Wallin wrote: [...]
Unrelated side note; what's up with the complicated path? Why don't we simply have https://svn.boost.org/trunk?
The same question applied to the trac urls: http://svn.boost.org/trac/boost/wiki ^^^^^ -- Daniel Wallin Boost Consulting www.boost-consulting.com
on Tue Aug 07 2007, Daniel Wallin <daniel-AT-boost-consulting.com> wrote:
Daniel Wallin wrote: [...]
Unrelated side note; what's up with the complicated path? Why don't we simply have https://svn.boost.org/trunk?
The same question applied to the trac urls:
I think the idea is that we have room to grow into a multi-trac and multi-svn-project setup. Personally I agree with you, though. The chance we'll need that generalization in the future doesn't justify the complexity. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
I really think this is worth addressing, and the sooner we do it the better. Daniel Wallin wrote:
Daniel Wallin wrote: [...]
Unrelated side note; what's up with the complicated path? Why don't we simply have https://svn.boost.org/trunk?
The same question applied to the trac urls:
-- Daniel Wallin Boost Consulting www.boost-consulting.com
Daniel Wallin wrote:
I really think this is worth addressing, and the sooner we do it the better. Daniel Wallin wrote:
Daniel Wallin wrote: [...]
Unrelated side note; what's up with the complicated path? Why don't we simply have https://svn.boost.org/trunk?
The same question applied to the trac urls:
We future-proofed the URLs, in case we need to add other subprojects that need their own Trac/Subversion repository but still fall under the Boost umbrella. - Doug
Daniel Wallin wrote:
Rene Rivera wrote:
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed! Simple question, regarding this:
Developers can ensure a stable development environment by checking out //svn.boost.org/svn/boost/release as their working copy, and then switching only the library they are working with to //svn.boost.org/svn/boost/trunk or a library specific development branch.
AFAIK subversion doesn't allow switching individual files, only directories. How would one switch for example "boost/regex.hpp"?
IIRC you can switch individual files:
svn switch \ https://svn.boost.org/svn/boost/branches/whatever/boost/regex.hpp \ boost/regex.hpp
Unrelated side note; what's up with the complicated path? Why don't we simply have https://svn.boost.org/trunk?
I figured out why the switch wasn't working for me... I was confusing the trunk vs. tags URIs and svn would delete the file on switch and not work afterwards since there was no file to reference. So I got bit by exactly the question you are asking. The long path makes for occasional mistakes. So I think I'll stick to using tsvn as much as possible. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
I think that the Trac wiki is a better place for this document. Weak points: 1. Merging from trunk to release. This is critical for the success of the whole scheme, but the details are still to be worked out. It's not clear whether tools can help much since we're talking about merges across two independent parallel branches without a close common ancestor, but I can be wrong. 2. Testing core libraries on branches. Not clear how or who, or even whether at all. 3. Trunk. Unclear what would prevent the current wild west syndrome, except for the continuous testing; but if this is all that it takes, why didn't we institute this policy earlier? Some comments on core libraries: "Note that the requirements for being release-ready are transitive; if a library has dependent libraries, it isn't considered release-ready if it breaks any of those dependent libraries." This is sensible but it can prevent progress if these failures are caused by the dependencies rather than the core library. Two arbitrary shared_ptr examples: (1) the serialization library in 1.32 relying on implementation details, (2) Spirit using the long deprecated make_shared spelling of weak_ptr::lock. A failure downstream is caused by either (1) insufficient test coverage in the core library, (2) a "bug" (broadly speaking) in the dependency. We still don't have a proper policy to address (1). We don't ask people to contribute tests, and we don't (in general) add tests when we fix bugs. Looking at the big picture, all Boost libraries are core, because the World depends on them. The World however doesn't get to receive the preferential treatment that non-core Boost libraries enjoy; it relies on bug reports. I'm not saying that this is a good or bad thing, just a food for thought. Finally, a philosophical point. I'm slowly coming to the realization that the problem we're having is not caused by lack of process or lack of tools. It's caused by the fact that release management (at this point) is a full time job.
Peter Dimov wrote:
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
I think that the Trac wiki is a better place for this document.
OK. Time to learn yet another set of wiki markup rules. Time passes... Done. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices The links within the page don't work because I couldn't figure out how to do anchors like <a name="#foo">foo</a>. If anyone knows how, please let me know:-) The docs seem to keep it a secret.
Weak points:
1. Merging from trunk to release. This is critical for the success of the whole scheme, but the details are still to be worked out. It's not clear whether tools can help much since we're talking about merges across two independent parallel branches without a close common ancestor, but I can be wrong.
I'm also concerned about merging from trunk to release, and have been giving it more thought. It really isn't a merge; it is more like updating a "Release_Candidate" tag. In Subversion, it would be done via the svn copy command. I've updated the wiki page to use the correct Subversion terminology. Before we actually try to do such a copy, we can experiment with a test repository to make sure we've got the SVN command sequence right.
2. Testing core libraries on branches. Not clear how or who, or even whether at all.
Testing will certainly be needed, but I'm not sure whether that will be on a regular or as-needed basis.
3. Trunk. Unclear what would prevent the current wild west syndrome, except for the continuous testing; but if this is all that it takes, why didn't we institute this policy earlier?
Nobody thought of it? Lack of clear policies?
Some comments on core libraries:
"Note that the requirements for being release-ready are transitive; if a library has dependent libraries, it isn't considered release-ready if it breaks any of those dependent libraries."
This is sensible but it can prevent progress if these failures are caused by the dependencies rather than the core library. Two arbitrary shared_ptr examples: (1) the serialization library in 1.32 relying on implementation details, (2) Spirit using the long deprecated make_shared spelling of weak_ptr::lock.
Yes, a definite problem. It's similar if not the same as the "breaking change" problem. I'm not sure we can work out solutions to all problems ahead of time. But as problems come up and get solved, we will need to update our procedures and development practices docs to deal with various situations.
A failure downstream is caused by either (1) insufficient test coverage in the core library, (2) a "bug" (broadly speaking) in the dependency. We still don't have a proper policy to address (1). We don't ask people to contribute tests, and we don't (in general) add tests when we fix bugs.
My sense is that lots of Boost developers feel strongly that we need to change, and are willing to endure a period of experimentation while we come up with better policies, better tools, and whatever else needs to be done to make the Boost development process more fun and less pain.
Looking at the big picture, all Boost libraries are core, because the World depends on them. The World however doesn't get to receive the preferential treatment that non-core Boost libraries enjoy; it relies on bug reports. I'm not saying that this is a good or bad thing, just a food for thought.
Yep.
Finally, a philosophical point.
I'm slowly coming to the realization that the problem we're having is not caused by lack of process or lack of tools. It's caused by the fact that release management (at this point) is a full time job.
It's certainly a full-time job with the old processes. It might still be, even with new and better processes and tools. There will be an announcement in a few days that Boost has formally (and legally) joined the Software Freedom Conservancy. That opens up funding options we haven't had in the past. It has seemed to me for a long time that when Boost gets big enough to pay someone, the first priority would be for a release manager. Thanks, --Beman
On 8/7/07, Beman Dawes <bdawes@acm.org> wrote:
[...]
Done. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The links within the page don't work because I couldn't figure out how to do anchors like <a name="#foo">foo</a>. If anyone knows how, please let me know:-) The docs seem to keep it a secret.
Good question :-) The only "pretty" way I can find of defining an anchor is by using a heading: ==== Release-ready ==== (then you can link to it as #Release-ready). If you want to specify an ID explicitly (e.g., to make it lowercase as you link to them in the wiki page): ==== Release-ready ==== #release-ready If you don't want to use headings for your definitions, you can resort to: {{{ #!html <a name="release-ready" /> }}} That's all I could figure out. HTH, Stjepan
Stjepan Rajko wrote:
On 8/7/07, Beman Dawes <bdawes@acm.org> wrote:
[...]
Done. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The links within the page don't work because I couldn't figure out how to do anchors like <a name="#foo">foo</a>. If anyone knows how, please let me know:-) The docs seem to keep it a secret.
Good question :-) The only "pretty" way I can find of defining an anchor is by using a heading:
==== Release-ready ====
(then you can link to it as #Release-ready). If you want to specify an ID explicitly (e.g., to make it lowercase as you link to them in the wiki page):
==== Release-ready ==== #release-ready
If you don't want to use headings for your definitions, you can resort to:
{{{ #!html <a name="release-ready" /> }}}
That's all I could figure out.
Thanks. Darren Garvey kindly went through the page and made the changes. --Beman
on Wed Aug 08 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Stjepan Rajko wrote:
On 8/7/07, Beman Dawes <bdawes@acm.org> wrote:
[...]
Done. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The links within the page don't work because I couldn't figure out how to do anchors like <a name="#foo">foo</a>. If anyone knows how, please let me know:-) The docs seem to keep it a secret.
Good question :-) The only "pretty" way I can find of defining an anchor is by using a heading:
==== Release-ready ====
(then you can link to it as #Release-ready). If you want to specify an ID explicitly (e.g., to make it lowercase as you link to them in the wiki page):
==== Release-ready ==== #release-ready
If you don't want to use headings for your definitions, you can resort to:
{{{ #!html <a name="release-ready" /> }}}
That's all I could figure out.
Thanks. Darren Garvey kindly went through the page and made the changes.
Internal links are easy when you write restructuredtext blocks. {{{ #!rst jump to `an internal link`_. .. _an internal link: whatever }}} -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
on Tue Aug 07 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
"Note that the requirements for being release-ready are transitive; if a library has dependent libraries, it isn't considered release-ready if it breaks any of those dependent libraries."
This is sensible but it can prevent progress if these failures are caused by the dependencies rather than the core library. Two arbitrary shared_ptr examples: (1) the serialization library in 1.32 relying on implementation details, (2) Spirit using the long deprecated make_shared spelling of weak_ptr::lock.
That's a real problem. We need a way to override the normal process when things like this happen. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
on Tue Aug 07 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Finally, a philosophical point.
I'm slowly coming to the realization that the problem we're having is not caused by lack of process or lack of tools. It's caused by the fact that release management (at this point) is a full time job.
Philosophical? Sounds entirely practical to me. Peter, with all due respect (and much is due), "no duh!" The question is, what makes it a full time job? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
On Aug 8, 2007, at 7:39 AM, David Abrahams wrote:
on Tue Aug 07 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
Finally, a philosophical point.
I'm slowly coming to the realization that the problem we're having is not caused by lack of process or lack of tools. It's caused by the fact that release management (at this point) is a full time job.
Philosophical? Sounds entirely practical to me.
Peter, with all due respect (and much is due), "no duh!" The question is, what makes it a full time job?
A few things come to mind, belatedly. It's a big job, because Boost is a big collection of libraries. It's a hard job, involving cat herding and code herding. It's not the kind of job that many eyeballs make shallow.
Beman Dawes wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
The proposed process refinements are meant to complement the parallel ongoing efforts to improve our tools, but don't depend on any tool improvements. Thus we can get started as soon as we reach sufficient consensus. That said, I think tools are very important, and hope we can rapidly make improvements in both process and tools.
I have those questions: 1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything. Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still? 2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released? 3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree? Trunk might be in the middle on the next big change, so a fix can either (1) be made on brunch and then merged, or (2) be made on release-ready tree directly. (1) requires on-demand testing of branches. Is (2) the way to go? - Volodya
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Tue Aug 07 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
I know you are really looking for comments about substance, so please forgive this nitpicking... but I think the Boost Trac is our future, especially where documentation for developers is concerned, and I think this sort of material ought to be developed there. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Tue Aug 07 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
A draft "Development and Release Practices" document is up on the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_A...
Comments welcomed!
I know you are really looking for comments about substance, so please forgive this nitpicking... but I think the Boost Trac is our future, especially where documentation for developers is concerned, and I think this sort of material ought to be developed there.
Yeah, Peter made that point too. The page has been moved to Trac accordingly. --Beman
participants (16)
-
Beman Dawes -
Daniel Wallin -
David Abrahams -
Douglas Gregor -
Greer, Joe -
Greg Colvin -
Joe Gottman -
John Maddock -
Marcus Lindblom -
Paul A Bristow -
Peter Dimov -
Rene Rivera -
Robert Ramey -
Stefan Seefeld -
Stjepan Rajko -
Vladimir Prus