On Thu, Jun 10, 2010 at 5:54 PM, Daniel James <dnljms@gmail.com> wrote:

On 10 June 2010 16:54, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:

...

I notice that Monday is the deadline for closing the 1.44 release to new libraries.  Boost.Polygon is checked into the trunk and more or less passing tests on all the platforms I expect tests to pass.  Is there any possibility of making it into the 1.44 release?

Yes. It isn't a hard deadline, it's set quite early so that we have plenty of time to deal with any issues that crop up.

I'd like to see the inspection problems markedly reduced or eliminated. See http://boost.cowic.de/rc/inspect-trunk.html#polygon --Beman

On 6/11/2010 11:16 AM, Simonson, Lucanus J wrote:

Almost all the inspect problems are in autogenerated html created when I tried to save my boostcon2009 presentation as html. Since the results of the conversion were terrible I am considering yanking that and posting the ppt file instead.

You might consider including a PDF of that presentation instead. As it's more immediately generally readable. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On Fri, Jun 11, 2010 at 12:51 PM, Michael Caisse <boost@objectmodelingdesigns.com> wrote:

Rene Rivera wrote:

...

On 6/11/2010 11:16 AM, Simonson, Lucanus J wrote:

...

Almost all the inspect problems are in autogenerated html created when I tried to save my boostcon2009 presentation as html.  Since the results of the conversion were terrible I am considering yanking that and posting the ppt file instead.

You might consider including a PDF of that presentation instead. As it's more immediately generally readable.

+1

Another +1. --Beman

On 14 June 2010 19:42, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:

I just checked in fixes for all the inspect errors that were left in the docs.  Is it OK or me to merge to release branch?

Sorry, I just noticed that no one's answered this. It looks good to me. Daniel

On 21 June 2010 19:58, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:

I have checked boost/polygon and libs/polygon into the release branch.  I have not merged any of the changes made to other files in the trunk that I edited as part of the new library checklist.  Who normally merges these files?

Anyone can. I'll go through the checklist for the new libraries later tonight, and I'll do it then. thanks, Daniel

Thomas Klimpel wrote:

Simonson, Lucanus wrote:

...

...

...

I just checked in fixes for all the inspect errors that were left in the docs. Is it OK or me to merge to release branch? [snip]

I have checked boost/polygon and libs/polygon into the release branch.

Why did you "checkin" instead of "merge"? You had asked for permission to "merge", not for permission to do an "initial checkin". I'm not subversion expert enough to know whether this will cause trouble for the merge tracking or not, but I don't understand why you preferred an "initial checkin" over the recommended "merge".

Because I am used to using add and commit and less used to using merge. I am not an SVN expert either. I followed the same procedure as when I "merged" from the sandbox to the trunk, which was to copy the directory structure over, add it to the trunk and then commit the new files. There may be metadata that would have been created by a merge command that is absent, as you suggest. There may be more potential for a botched checkin of partial copy than a botched merge because I am manually doing some extra steps that the tool might do for me. Indeed, the images and sample code for my Mikowski sum of polygon sets tutorial were somehow missing from the release branch and I have just added them in the release branch. I don't know why that happened and I can't say for sure whether I would have had the same problem merging as copying. I'm used to working in a different revision control system for every different project I am involved in and tend to get by using the minimal and sufficient set of features provided by the revision control system to get the job done since becoming a power user of N different systems is at cross purposes with getting any work done. I've worked on projects where all of the meta data for all files was corrupted and there was effectively no way to tell who checked in what and when or from where. Since file ownership was clear, the team small and communication and testing generally good this didn't pose much problem. In another project we extensivly tracked and managed branches for each and every of thousands of source files in great detail, the project was large, the build was brittle and knowing who checked in what and when, from where and for which release was a full time job for one out of ten developers of the hundreds involved. If dependencies are established on my library by other boost libraries I imagine that knowing which revision number of the trunk was merged to the release branch could become important. Thanks, Luke