Vladimir Prus | 24 Jul 09:16 2015
Picon

[Boost-users] Boost.DLL formal review result


The Boost.DLL library is accepted. Congratulations to Antony, and thanks for everybody who
reviewed the library!

The votes were as follows:

- Ralf Globisch - Yes
- Klaim - Joël Lamotte - Yes
- Niall Douglas - Yes, conditionally
- John P Fletcher - Yes
- Bjorn Reese - Yes
- Edward Diener - Yes
- Rodrigo Madera - Yes
- Richard - Yes

I'd like to also thank Thomas Trummer, Rob Stewart and Ion Gaztañaga for their contribution to review.

The key suggestions from the review are listed below. None is critical enough to become a formal prerequisite, or 
require a mini-review. The library can  be added when Antony feels its ready.

Naming
-----------

There was a concern that "DLL" might sound windows specific, and search for best terminology. This
does not seem all that important, as soon as documentation introduces the terminology it uses, and is consistent.

OSX support
-------------------

The library was found not to work on OSX; I believe this issue was already fixed off-list with help from Rodrigo.

Documentation
----------------------

Several people requested improvements. Bjorn and John, in particular, pointed out specific issues. This seems to be the post important
change prior to adding the library.

Dependencies on Boost and system headers
----------------------------------------------------------------

It was suggested that the library does not depend on other Boost C++ Libraries. While it might be helpful to some users, I find it logically impossible for a Boost 
formal review to request that dependencies on Boost libraries be removed. 

It was also mentioned that Boost.DLL is header-only library and includes system headers that can bring a lot of symbols and maybe macros. I don't think an actual 
problem was reported, though, and there is no way to avoid the problem while staying header-only.

It's up to the author to consider these suggestions and do something, or don't do anything.

Continuous integration
--------------------------------

There was a recommendation from Niall to improve CI of the library, including static analysis, valgrind, Windows CI, showing CI status in documentation and so forth.
These are good suggestions. At the same time, they are not specific to Boost.DLL, and it's not the goal of a formal review to create new generic development 
process requirements. Many existing libraries of indisputably high quality do not have these requested mechanisms.

Therefore, the author can act on these suggestions as he sees fit.


Thanks,

--
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
<div>
<div dir="ltr">
<div><br></div>
<div>The Boost.DLL library is accepted. Congratulations to Antony, and thanks for everybody who</div>
<div>reviewed the library!</div>
<div><br></div>
<div>The votes were as follows:</div>
<div><br></div>
<div>- Ralf Globisch - Yes<br>
</div>
<div>- Klaim - Jo&euml;l Lamotte - Yes<br>
</div>
<div>- Niall Douglas - Yes, conditionally<br>
</div>
<div>- John P Fletcher - Yes<br>
</div>
<div>
<div>- Bjorn Reese - Yes</div>
<div>- Edward Diener - Yes</div>
<div>
<span>- Rodrigo Madera - Yes</span><br>
</div>
<div><span>- Richard - Yes</span></div>
</div>
<div><br></div>
<div>
<span>I'd like to also thank&nbsp;</span><span>Thomas Trummer,&nbsp;</span><span>Rob Stewart and&nbsp;</span><span>Ion Gazta&ntilde;aga for their contribution to review.</span>
</div>
<div><span><br></span></div>
<div>The key suggestions from the review are listed below. None is critical enough to become a formal prerequisite, or&nbsp;</div>
<div>require a mini-review. The library can &nbsp;<span>be added when Antony feels its ready.</span>
</div>
<div><span><br></span></div>
<div><span>Naming</span></div>
<div><span>-----------</span></div>
<div><span><br></span></div>
<div><span>There was a concern that "DLL" might sound windows specific, and search for best terminology. This</span></div>
<div><span>does not seem all that important, as soon as documentation introduces the terminology it uses, and is consistent.</span></div>
<div><span><br></span></div>
<div><span>OSX support</span></div>
<div><span>-------------------</span></div>
<div><span><br></span></div>
<div><span>The library was found not to work on OSX; I believe this issue was already fixed off-list with help from Rodrigo.</span></div>
<div><span><br></span></div>
<div>Documentation</div>
<div>----------------------</div>
<div><br></div>
<div>Several people requested improvements. Bjorn and John, in particular, pointed out specific issues. This seems to be the post important</div>
<div>change prior to adding the library.</div>
<div><br></div>
<div>Dependencies on Boost and system headers</div>
<div>----------------------------------------------------------------</div>
<div><br></div>
<div>It was suggested that the library does not depend on other Boost C++ Libraries. While it might be helpful to some users, I find it logically impossible for a Boost&nbsp;</div>
<div>formal review to request that d<span>ependencies on Boost libraries be removed.&nbsp;</span>
</div>
<div><br></div>
<div>It was also mentioned that Boost.DLL is header-only library and includes system headers that can bring a lot of symbols and maybe macros. I don't think an actual&nbsp;</div>
<div>problem was reported, though, and there is no way to avoid the problem while staying header-only.</div>
<div><br></div>
<div>It's up to the author to consider these suggestions and do something, or don't do anything.</div>
<div><br></div>
<div>Continuous integration</div>
<div>--------------------------------</div>
<div><br></div>
<div>There was a recommendation from Niall to improve CI of the library, including static analysis, valgrind, Windows CI, showing CI status in documentation and so forth.</div>
<div>These are good suggestions. At the same time, they are not specific to Boost.DLL, and it's not the goal of&nbsp;<span>a formal review to create new generic development&nbsp;</span>
</div>
<div><span>process requirements. Many existing libraries of indisputably high quality do not have these requested mechanisms.</span></div>
<div><br></div>
<div>Therefore, the author can act on these suggestions as he sees fit.</div>
<div><br></div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Vladimir Prus<div><a href="http://vladimirprus.com/" target="_blank">http://vladimirprus.com</a></div>
</div></div>
</div>
_______________________________________________<br>Boost-users mailing list<br><a href="mailto:Boost-users <at> lists.boost.org">Boost-users <at> lists.boost.org</a><br>http://lists.boost.org/mailman/listinfo.cgi/boost-users</div>
Christophe Henry | 11 Jul 21:49 2015
Picon

[boost] [review] Metaparse Review Result

Hi all,

First of all, the final result.
Metaparse is formally unconditionally accepted into Boost.

We had 11 reviews, all "Yes" votes. 2 "No" reviews based on formality were
later reversed to a "Yes".

The review was lively, with a general agreement that the library is very
useful, the design of high quality and the documentation great.
Here are some noticeable quotes which helped me take my decision:
- "thank you Abel for submitting such an amazing library.
The quality of the documentation and code is wonderful and
it has been a pleasure to review Metaparse." (Michael Caisse)
- (Design) "Of high quality. Based on the MPL paradigm, but I don't view
this as a problem." (Peter Dimov)
- "Part of the role of boost is to push compilers to the limit (and
sometimes beyond).
This library certainly has the capabilities to do so." (Roland Bock)

Worth noticing is the review of Gordon Woodhull. I myself wrote a new
front-end for MSM using Metaparse, and other use cases were very welcome
and Gordon managed to produce one for his compile-time graph library by the
end of the review, which I found impressive (for both the reviewer and the
library). Thank you for investing time in this review.

Another important factor for me for acceptance is how well the author is
going to maintain his library. We have too many abandoned libraries.
Abel went out of his way to oblige remarks and demands made by reviewers.
Long before the reviews he also had obliged my many critics and demands. He
also showed himself open for experiments. All this while keeping a very
calm and professional tone.
This is for me a very good sign of a library which will be well-maintained.

Finally, there were some repeated important comments which I see as
adressed to the rest of Boost that the library is targeted towards library
writers.
From Peter Dimov:
> - Are you knowledgeable about the problem domain?
"I'm not sure if anybody is. :-)"

It all depends on us, library and potential library writers to become
knowledgeable about this domain and make this library move from potentially
useful to very useful. We need to use it to write more cool libraries.
I notice a recurring theme where Boost would be dead or on the way to doom
etc etc.
Some very popular Boost libraries are now part of the Standard, and so
what? We need to make new ones.
Metaparse is one of them. Let's build more, using it!

Yes Reviews(11):

Andrzej Krzemienski

Bjorn Reese

Gordon Woodhull

Lee Clagett

Louis Dionne

Michael Caisse

Paul A. Bristow

Peter Dimov

Roland Bock

Edward Diener

Niall Douglas

I want to thank all the reviewers who invested their time in this review
and those who provided some usefuls comments.

I also want to thank Abel for presenting this great library.

Christophe Henry

Metaparse Review Manager

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Marshall Clow | 16 Jul 15:16 2015
Picon

Boost release 1.59.0 beta 1 is now available from SourceForge


Boost release 1.59.0 beta 1 is now available from SourceForge
See http://sourceforge.net/projects/boost/files/boost/1.59.0.beta.1/
For details of what's in the release, see http://www.boost.org/users/history/version_1_59_0.html
Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files.
Please download the beta, give it a try, and report any problems you encounter.
Thanks,

-- The Boost Release Team

<div><div dir="ltr">
<br>Boost release 1.59.0 beta 1 is now available from SourceForge<br>See <a href="http://sourceforge.net/projects/boost/files/boost/1.59.0.beta.1/">http://sourceforge.net/projects/boost/files/boost/1.59.0.beta.1/</a><br>For details of what's in the release, see <a href="http://www.boost.org/users/history/version_1_59_0.html">http://www.boost.org/users/history/version_1_59_0.html</a>.&nbsp;<br>Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files.<br>Please download the beta, give it a try, and report any problems you encounter.<br>Thanks,<br><br>-- The Boost Release Team<div><br></div>
</div></div>
Vladimir Prus | 3 Jul 15:50 2015
Picon

[boost] Boost.DLL formal review is ongoing


The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week.
As of today, over 100 people read through the library's tutorial, suggesting quite some interest.
However, no reviews were submitted yet. Please take the time to post your thoughts - even if you
don't have time to do a full review, or try the library, comments on design and interfaces are
still very valuable.

The summary of the library features and review checklists are reproduced below.

Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library
provides a portable across platforms way to:

  - load libraries at runtime
  - import and export any native functions and variables
  - make alias names for C++ mangled functions and symbols
  - query libraries/objects and executables for sections and exported
  symbols
  - self loading and self querying
  - getting program and module location by exported symbol

The documentation can be found at:

   http://apolukhin.github.io/Boost.DLL/index.html

and the source can be obtained at:

   https://github.com/apolukhin/Boost.DLL

Please post your reviews on the mailing list and if possible, answer the
following questions:

- Should the library be accepted?
- How useful is it?
- What's your evaluation of
 - Design
 - Implementation
 - Documentations
 - Tests
- How much effort did you put into your evaluation?
- Did you attempt to use the library? On what systems and compilers?

Thanks,
Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Glen Fernandes | 7 Jul 07:42 2015
Picon

Boost.Hana

Dear Ron, Louis, and Boost developers,

The review period for Hana has concluded. 18 reviews were submitted:
- 17 votes for acceptance. (1 of these was conditional upon Hana
  wholly supporting a second C++ implementation however).
- 1 vote for rejection; for lack of compiler support.

I submit that Hana be accepted into Boost. I want to congratulate Louis:
the Boost community wants Hana to become an official Boost library.
Thank you again, Louis, for your work on Hana and for contributing it
to Boost.

I propose we require, prior to Hana's inclusion in a Boost release, only
that:
1. Hana's unit tests to be integrated into Boost's regression tests. If
   this requires maintaining both CMakeLists.txt and .b2 files, it is
   still worth it. I am willing to assist with this effort (and the
   invitation extends to anyone in the community to also contribute to
   the task). For release managers, potential Hana contributors, or just
   the general developer community in Boost, to see Hana's test cases in
   http://boost.org/development/tests/master/developer/summary.html will
   be useful.

I trust, but do not mandate before Hana is officially accepted into
Boost, that:
1. All GitHub issues pertaining to implementation and documentation that
   were opened by Louis in response to review feedback (or by others,
   such as Vincente, that were approved by Louis) will be addressed
   eventually (as long as they remain relevant).

I personally would ask for, but do not require for Hana's acceptance,
that:
1. That Hana's non-reference documentation live outside of the source
   code. The presentation of Hana's documentation is great; it looks
   modern, is easy to browse. I am not a fan of the prose living inside
   hana.hpp though (API reference documentation is the only exception).
2. Louis to investigate further the possibility of a Hana core library
   if such can be achieved with zero overhead (instead of focusing that
   effort onto a separate library that provides only a subset of Hana's
   functionality).

On the note of Hana's current support in existing C++ implementations:
- While Hana is wholly only supported by clang at present, gcc is not
  far behind. Given the trend of language conformance, it is reasonable
  to expect Hana will be entirely supported in a future gcc release.
- Hana targets the C++ standard (i.e. This isn't a case of targeting
  any compiler-vendor specific extensions) and any highly-contentious
  C++ language features within (e.g. This isn't something like a
  pre-C++11 library that uses 'export' that only builds with an EDG
  compiler).
- The community now has expressed sufficient interest in both kinds of
  libraries being part of Boost: Highly portable libraries that target
  implementation-specific features, and maintain compatibility with even
  legacy compilers; standard conforming, modern, libraries that are free
  of the maintenance debt of ancient compiler support.
- We need more libraries taking advantage of C++14 language features to
  drive vendor conformance. A standard may only be as potent as the
  C++ implementations that support support it, but when one (such as
  clang does) does, others will be more driven to follow suit when
  real (and highly desired) projects take advantage of it.

My thanks to everyone that participated in Hana's review with a
review (Edouard, John Fletcher, John Bytheway, Niall, Krzysztof, Manuel,
Roland, Christophe, David Stone, David Sankel, Lorenzo, John, Paul,
Zach, Kohei, Charley, Vincente, Abel) as well as discussion and bug
reports.

Best,
Glen
Glen Fernandes | 30 Jun 13:50 2015
Picon

[Boost] [Hana] Formal review for Hana (Submissions closed)

Dear Boost community,

The period for Hana review submissions has ended. The result will be
announced on the list during this week.

I would like to thank everyone on this list for your submission of a review:
- Edouard Alligand
- John P. Fletcher
- Niall Douglas
- Krzysztof Jusiak
- Roland Bock
- Vicente J. Botet Escriba
- David Sankel
- Zach Laine
- Kohei Takahashi
- Charley Bay
- Bruno Dutra
- Christophe Henry
- David Stone
- Lorenzo Caminiti
- John Bytheway
- Manuel Sánchez

As well as the following people for your discussion during the review period:
- Phil Endecott
- Larry Evans
- Abel SInkovics
- Gavin Lambert
- Jeremy Maitin-Shepard
- Joel de Guzman
- Edward Diener
- Paul A. Bristow
- Peter Dimov
- Bjorn Reese
- Paul Fultz II
- Lee Clagett

Once again, thank you to Louis for all your work on Hana and
submitting it for Boost inclusion.

Glen
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce
Glen Fernandes | 10 Jun 11:19 2015
Picon

[Boost] [Hana] Formal review for Hana

Dear Boost community,

The formal review of Louis Dionne's Hana library begins today,10th June
and ends on 24th June.

Hana is a header-only library for C++ metaprogramming that provides
facilities for computations on both types and values. It provides a
superset of the functionality provided by Boost.MPL and Boost.Fusion
but with more expressiveness, faster compilation times, and faster (or
equal) run times.

To dive right in to examples, please see the Quick start section of the
library's documentation:
http://ldionne.com/hana/index.html#tutorial-quickstart

Hana makes use of C++14 language features and thus requires a C++14
conforming compiler. It is recommended you evaluate it with clang 3.5 or
higher.

Hana's source code is available on Github:
https://github.com/ldionne/hana

Full documentation is also viewable on Github:
http://ldionne.github.io/hana

To read the documentation offline:
git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages

For a gentle introduction to Hana, please see:
1. C++Now 2015:
   http://ldionne.github.io/hana-cppnow-2015 (slides)
2. C++Con 2014:
   https://youtu.be/L2SktfaJPuU (video)
   http://ldionne.github.io/hana-cppcon-2014 (slides)

We encourage your participation in this review. At a minimum, kindly
state:
- Whether you believe the library should be accepted into Boost
  * Conditions for acceptance
- Your name
- Your knowledge of the problem domain.

You are strongly encouraged to also provide additional information:
- What is your evaluation of the library's:
  * Design
  * Implementation
  * Documentation
  * Tests
  * Usefulness
- Did you attempt to use the library? If so:
  * Which compiler(s)
  * What was the experience? Any problems?
- How much effort did you put into your evaluation of the review?

We await your feedback!

Best,
Glen
Glen Fernandes | 5 Jun 21:19 2015
Picon

[Boost] [Hana] Formal review for Hana next week (June 10th)

Dear Boost community,

The formal review of Louis Dionne's Hana library starts Monday, 10th
June and ends on 24th June.

Hana is a header-only library for C++ metaprogramming that provides
facilities for computations on both types and values. It provides a
superset of the functionality provided by Boost.MPL and Boost.Fusion
but with more expressiveness, faster compilation times, and faster (or
equal) run times.

To dive right in to examples, please see the Quick start section of the
library's documentation:
http://ldionne.com/hana/index.html#tutorial-quickstart

Hana makes use of C++14 language features and thus requires a C++14
conforming compiler. It is recommended you evaluate it with clang 3.5 or
higher.[1]

Hana's source code is available on Github:
https://github.com/ldionne/hana

Full documentation is also viewable on Github:
http://ldionne.github.io/hana

To read the documentation offline:
git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages

For a gentle introduction to Hana, please see:
1. C++Now 2015:
   http://ldionne.github.io/hana-cppnow-2015 (slides)
2. C++Con 2014:
   https://youtu.be/L2SktfaJPuU (video)
   http://ldionne.github.io/hana-cppcon-2014 (slides)

We encourage your participation in this review. At a minimum, kindly
state:
- Whether you believe the library should be accepted into Boost
- Your name
- Your knowledge of the problem domain.

You are strongly encouraged to also provide additional information:
- What is your evaluation of the library's:
  * Design
  * Implementation
  * Documentation
  * Tests
  * Usefulness
- Did you attempt to use the library? If so:
  * Which compiler(s)?
  * What was the experience? Any problems?
- How much effort did you put into your evaluation of the review?

[1] A note for Windows users: As mentioned, Hana requires a C++14
conforming compiler. If you would like to try it, a VM with Linux and
clang 3.5 is a fairly painless option. Some users have also reported
success with using Clang 3.5 on Windows. If you would like assistance
configuring the former option, feel free to reach out to us for this.

Best,
Glen
Christophe Henry | 19 May 23:39 2015
Picon

[boost] [metaparse] Review period starts May 25th and ends June 7th

Dear all,

The review of the Metaparse library starts next Monday, May 25th and ends
June 7th. Metaparse was written by Abel Sinkovics.

Metaparse is a parser generator library for template metaprograms.
The purpose of this library is to support the creation of parsers that
parse at compile time.
This library is intended to be used for embedded domain specific language
creation for C++ and can help libraries provide a better interface.
It is similar to Boost.Spirit, however while parsers built with Spirit
parse at run-time, parsers built with Metaparse parse at compile-time.
It makes it possible for library authors to provide an interface that
follows the common notation of the problem domain of the library.
(eg. SQL queries, grammars, etc written in their common notation instead of
similar-looking C++ expressions).
For example there is a (yet incomplete) interface for Boost.Spirit that
makes it possible to write

 MPLLIBS_REGEX("^[abcd][3-8]\\.foo$")

instead of

 bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >>
'o' >> 'o' >> eos

and make the parser built with Metaparse generate the latter expression
from the former one.

(It can be found here:
https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive)

Since the library is based on template metaprogramming, the DSLs can be
used for type validation as well.
This is demonstrated by the type-safe printf implementation (
http://abel.web.elte.hu/mpllibs/safe_printf/index.html).
It type-checks the arguments of a printf call based on the format string
and has zero runtime overhead compared to unchecked printf.

Parsers can be constructed in a declarative manner and (even though this is
template metaprogramming based) remain readable.
The implementation reflects the grammar it parses (with additional elements
for semantic actions).
Even though the library requires the parser author to write template
metaprograms, the development of parsers is well supported by tools like
Metashell and MDB.

An important aspect of parsers (built with this library or another one) is
error reporting for invalid input.
The library offers tools for the parser authors to be able to provide
useful error messages in case of parsing errors.
Here is an example error report by a parser built with Metaparse (the
parser can be found in the Getting Started guide of the library):

..... x__________________PARSING_FAILED__________________x<1, 5,
unpaired<1, 1, literal_expected<')'>>> ....

It is an error report letting the developer know that a closing paren is
missing at line 1, column 5 and the unclosed opening paren is in line 1,
column 1.

Metaparse can be downloaded from Github:

https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse

And a very complete tutorial:

http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html

The tutorial also offers the nice feature of a link to metashell for
quick-starting trying out the library:

http://abel.web.elte.hu/shell/metashell.html

Boost.Msm v3 also implements a new compile-time strings based front-end
called eUML2 to demonstrate the power of the library and the conciseness
and expressiveness it allows.
Please have a look at the documentation:

https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/msm/msm3/doc/HTML/ch03s05.html

Everybody on this list is invited to participate in this formal
review. I hope to see your review of Metaparse, including your vote on
acceptance, and I welcome your participation in the ensuing discussions
on the Boost developers' mailing list.

Please always include in your review a vote as to whether the library
should be accepted into Boost.

Additionally please consider giving feedback on the following general
topics:

- What is your evaluation of the design?
- What is your evaluation of the implementation?
- What is your evaluation of the documentation?
- What is your evaluation of the potential usefulness of the library?
- Did you try to use the library?
 - With what compiler?
 - Did you have any problems?
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
- Are you knowledgeable about the problem domain?

Regards,

Christophe
Review Manager

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Niall Douglas | 28 Apr 01:12 2015

[gsoc15] This year's GSoC students

Dear Boost,

It is our pleasure to announce this year's winning GSoC students and 
projects:

1. Damian Vicino
Topic: Safe Float (boost::safe_numerics<float>)
Mentor: Robert Ramey

2. Rajaditya Mukherjee
Topic: Boost uBLAS EigenSolver
Mentor: David Bellot

3. Anurag Ghosh
Topic: Boost Document Library
Mentor: Antony Polukhin

4. Nikhar Agrawal
Topic: Boost.Fixed-Point
Mentor: Paul A. Bristow

5. Benedek Thaler
Topic: Enhanced vector and deque containers
Mentor: Thorsten Ottosen

6. Louis Dionne
Topic: Improved compile-time associative data structures for Hana
Mentor: Joel Falcou

7. Jakub Szuppe
Topic: Improving Boost.Compute
Mentor: Kyle Lutz

Congratulations to these students for passing an exceptionally tough 
contest this year, and our thanks to the above mentors for making 
themselves available. Finally, thank you Google for another year of 
funding and to those open source orgs who released duplicate students 
to us, we appreciate it!

Niall and Boris

--- 
Boost C++ Libraries Google Summer of Code 2015 admin
https://svn.boost.org/trac/boost/wiki/SoC2015

Niall Douglas | 27 Mar 22:12 2015

[gsoc15] Please help rank GSoC 2015 student projects

Dear Boost Community,

The Google Summer of Code 2015 proposals for Boost are in, and we 
would
deeply appreciate the community's help in ranking the proposals 
according
to merit before the 6th of April.

To vote, the process is easy:

1. Go to this page 
https://www.google-melange.com/gsoc/homepage/google/gsoc2015 and 
click the
"Log in" button under Mentors and Administrators.

2. Now click "Create Profile" on the same page. Note that even if you
registered last year, you must register again in 2015. Fill in the 
form.
Note that after submitting it drops you at "Edit Profile", which is
confusing.

3. Click "My Dashboard", then "Connect with organisations".

4. Choose "Boost C++ Libraries".

5. In the message box, write this: "I am a member of the Boost 
community
and the email(s) I normally post to boost mailing lists with is 
<email>"
filling in the email address(es) you normally use to post to boost 
mailing
lists. This lets us verify that you are indeed a long standing member 
of
the Boost community.

6. Once we approve your request, you will get an email with the 
subject
"Welcome as organisation member". You can now return to the Dashboard 
on
the GSoC website where there will be a new item "Proposals".

7. Work your way through as many of the 33 proposals as you can. You 
can
score them using the stars at the bottom of each proposal page, 
taking
care to read any comments by the mentors and students if present. 
PLEASE
try to rank some of the lowest scored proposals, every year we get a 
lot
of people who only rank the top five and don't bother with the rest.

Try to score on the priority basis of:

(i) ability to write quality C++, using the programming competency 
test or samples of programming the student supplied.

(ii) proposal quality and your best estimate of the student's 
understanding of how best to solve the problem at hand. Bear in mind 
a gifted programmer with a strong work ethic but poor English may 
appear to not understand the problem as well as native English 
speakers, this is why we have asked for examples of their programming 
competency.

(iii) if the student came early to the mailing lists to ask for help 
writing the proposal (the mentors who helped them with their 
proposals have usually indicated this in the private comments).

(iv) usefulness/appropriateness of the feature or work being 
proposed.

Remember a good GSoC is more about getting promising new engineers 
into Boost and C++ than necessarily getting code to pass Boost peer 
review in a single summer.  

8. Optional: If a proposal looks especially great to you and you feel 
able
to mentor a student this year, please slide the "wish to mentor" 
button.
Just because a proposal already has willing mentors does NOT mean you
should not add yourself - if you can substitute for an existing 
mentor, that may mean we use that mentor for another proposal.

As you know, Google Summer of Code is usually worth $42,000 - $48,000 
to
Boost each year, and a successful GSoC raises our visibility and
reputation in the wider open source community. Our thanks to you in
advance for taking the time to vote.

Niall Douglas
Boris Schäling

--- 
Boost C++ Libraries Google Summer of Code 2015 admin
https://svn.boost.org/trac/boost/wiki/SoC2015

Attachment (SMime.p7s): application/x-pkcs7-signature, 8 KiB
Dear Boost Community,

The Google Summer of Code 2015 proposals for Boost are in, and we 
would
deeply appreciate the community's help in ranking the proposals 
according
to merit before the 6th of April.

To vote, the process is easy:

1. Go to this page 
https://www.google-melange.com/gsoc/homepage/google/gsoc2015 and 
click the
"Log in" button under Mentors and Administrators.

2. Now click "Create Profile" on the same page. Note that even if you
registered last year, you must register again in 2015. Fill in the 
form.
Note that after submitting it drops you at "Edit Profile", which is
confusing.

3. Click "My Dashboard", then "Connect with organisations".

4. Choose "Boost C++ Libraries".

5. In the message box, write this: "I am a member of the Boost 
community
and the email(s) I normally post to boost mailing lists with is 
<email>"
filling in the email address(es) you normally use to post to boost 
mailing
lists. This lets us verify that you are indeed a long standing member 
of
the Boost community.

6. Once we approve your request, you will get an email with the 
subject
"Welcome as organisation member". You can now return to the Dashboard 
on
the GSoC website where there will be a new item "Proposals".

7. Work your way through as many of the 33 proposals as you can. You 
can
score them using the stars at the bottom of each proposal page, 
taking
care to read any comments by the mentors and students if present. 
PLEASE
try to rank some of the lowest scored proposals, every year we get a 
lot
of people who only rank the top five and don't bother with the rest.

Try to score on the priority basis of:

(i) ability to write quality C++, using the programming competency 
test or samples of programming the student supplied.

(ii) proposal quality and your best estimate of the student's 
understanding of how best to solve the problem at hand. Bear in mind 
a gifted programmer with a strong work ethic but poor English may 
appear to not understand the problem as well as native English 
speakers, this is why we have asked for examples of their programming 
competency.

(iii) if the student came early to the mailing lists to ask for help 
writing the proposal (the mentors who helped them with their 
proposals have usually indicated this in the private comments).

(iv) usefulness/appropriateness of the feature or work being 
proposed.

Remember a good GSoC is more about getting promising new engineers 
into Boost and C++ than necessarily getting code to pass Boost peer 
review in a single summer.  

8. Optional: If a proposal looks especially great to you and you feel 
able
to mentor a student this year, please slide the "wish to mentor" 
button.
Just because a proposal already has willing mentors does NOT mean you
should not add yourself - if you can substitute for an existing 
mentor, that may mean we use that mentor for another proposal.

As you know, Google Summer of Code is usually worth $42,000 - $48,000 
to
Boost each year, and a successful GSoC raises our visibility and
reputation in the wider open source community. Our thanks to you in
advance for taking the time to vote.

Niall Douglas
Boris Schäling

--- 
Boost C++ Libraries Google Summer of Code 2015 admin
https://svn.boost.org/trac/boost/wiki/SoC2015


Gmane