----- Original Message ----- From: "Robert Ramey" To: Cc: Sent: Saturday, November 22, 2008 9:19 PM Subject: Re: [Boost-users] Maintenace Guidelines wiki page

This is a laudable effort,

Thanks.

but my guess is that it's doomed to failure.

My own take on this was posted in http://lists.boost.org/Archives/boost/2008/07/139893.php

I remember your participation and your point of view on this long thread.

So far, no one else has endorsed such a pledge. Indeed, the responses suggested that the breaking interfaces was a normal, acceptable and unavoidable practice.

I don't think this is the case. Breaking changes should be exceptional and taken because there is no better solution. I think that most of the Boost authors respect that. As every rule this one has its exceptions, there has been some library evolution that have break user and even Boost library code. This is regretable and we need to setup whatever is needed to make this exceptions more than exceptional. I really think that *we can* achieve this goal.

I think that differing points of view reflect different backgrounds of different developers. In my particular case, I work on relatively short term projects under huge pressure to produce results. I absolutely depend upon boost and other libraries (e.g. MFC) to get the job done. If a library changes, then I have to go back and re-visit something that was already considered "finished". The creates a big problem for me.

I understand your concern.

In other environments, programmers work on huge projects which might go on for years. In this constext, this is not such a huge problem as things are constantly evolving anyway. So continuing to break things and having to fix them is a normal and in any event unavoidable.

Even in this case breaking code is a inacceptable because there is a lot of code to modify and test. So if we want that the Boost library is used widely we need to *try* to provide backward compatible versions, and warm when this is no more possible. In my personal work, we use to do provide some scripts that either they are able to automaticaly do the complete transformation or they warm when automatic transformation is not possible. Usualy this let 20% of the code to be transformed manually.

Your "Maintainence Guidlines" presume a consensus about what should be acceptable practice where no such consensus actually exists.

Which acceptable practice are you referring to for which there is no consensus?

As a practical matter what do I do.

I need a facility. My experience would suggest that such a facility might be already existing in some sort of library. According to the situation, I will review a couple of candidates and select one to try. It might be a commercial product or it might be something like boost. Then I'll try to introduce the library to my code. This has to be pretty easy or I'll discard it. It needs to have good documentation and it needs to "just work" I then copy the library in to my project. I try to avoid making a big commitment to a library - or anyone else's code so that I can drop one library if I have to in the future.

With the serialization library, it has to include the latest boost libraries that it uses. If I find that the library author can't maintain a stable and relieable product, I design that library out of the serialization library. This has happened several times. Given the fact that the serialization library is not my full time job (though at times it seems that way), I don't feel there is any real alternative.

I hope that you are not proposing that to the end users. Are you? Please could you participate in the elaboration of this guidelines, your opinion is very important to the Boost community. Thanks, Vicente

----- Original Message ----- From: "Tomas Puverle" To: Sent: Sunday, November 23, 2008 4:31 AM Subject: Re: [Boost-users] Maintenace Guidelines wiki page

...

I have started the Maintenace Guidelines wiki page.

You can access it directly https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines

or via https://svn.boost.org/trac/boost/wiki

Guidelines * Maintenance Guidelines

There page need to be completed and surely reworked but this is an starting point.

Please be free to improve the page directly or post your comments or suggestions to this list.

Hopping this goes on the right direction,

Vincente,

A few ideas: How will you evaluate that your proposal is actually successful and being followed by the boost developers?

Also, check out Daniel Walker's idea in the Boost.Range thread on boost.devel about not having the engineers in charge of their own QA. Daniel Walker's idea " Perhaps a procedural solution that could avert this problem in the future is to quarantine the test cases. Authors can maintain commit

Hi, First this is proposal for guidelines. So people will be after all free to follow some of them or not. I'm expecting from people like you to improve it so it could be followed by more people. privileges to their libraries on trunk, but only a select group of independent guardians have commit privileges to the test cases. That way there is a guarantee that libraries pass the same tests from one release to another. If an author would like to make a change that would break a test case, he or she would need to present the change to the list and submit a patch to the test case sentinels. This would be a fairly simple quality assurance protocol: engineers aren't allowed to do their own QA." This is already considered on the guidelines insome way. "Preserve the test from the preceding versions [author] The test from the preceding versions should not be changed when the author modifies its library. These not changed tests are a probe of compatibility with the preceding version. When these test must be changed they indicate a breaking user code issue. So instead of changing them add new ones stating explicitly on which version they were included. Old tests that should fail can be moved to the compile_fail or run_fail tests on the Jamfile. " The Daniel proposal implies some changes in the writing rights of the authors. I prefer to let this point out of these guidelines. Of course I think that this is a good idea. There is another guideline that could be used by the Boost comunity to check the author has not changed the old test cases. "Inspect announced modifications [author, user, RM] The use of the diff file will help to inspect that the modifications introduced have been correctly included on the documentation and a good test coverage has been done. This will result in a non official mini-review of the library. " I will add to check that the old testcases have not been changed.

Finally, please consider the idea of "core" and "new" release cycles, where the components in "core" have much more stringent requirements on how and when they are allowed to change.

IMO this is out of the scope of the guidelines. Note that at the end it is up to the author to make the modification he/she consider pertinent. Could you send what you have in mind in the form of guidelines?

Finally, do you think it may have been better to start this thread on boost.devel?

I belived that i did it on both. I'm answering to both each time. Should I start a new thread including the guidelines contents? Vicente