Boost, not LEWG

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[OT] Re: Boost, not LEWG

Boost - Dev mailing list
> The concrete items mentioned that have been known to inhibit
> participation appear to be:
> - Mailing lists

First.  Thank  you to  everyone that  continues to  make, and  has made,
Boost  what it  is and  what it  has provided.   It takes  an inordinate
amount  of  effort  to  produce  quality and  those  efforts  are  under
recognized and not overtly appreciated often enough.

I'm a  ML lurker and haven't  contributed to any review[*],  so probably
not  the  target audience  and  hence  the [OT],  but  as  a method  for
consuming and very  occasionally participating, the mailing  list is the
perfect medium.  It's an invaluable resource  for me to keep my thumb on
what the issues  are and what is  coming down the pipe  in new standards
and features.

I know  that forums can  be subscribed to in  concept, but so  far, I've
just stopped  following when  the switch happens.   A recent  example is
sqlite.  Quite honestly, web interfaces  are too obtrusive for this type
of content probably because I don't 'live' in a browser during my normal
computer time, a shell prompt ssh'ed to another shell.

My suggestion  is that before turning  off the ML, if  not already done,
collect some data  and follow up with some projects  that have done that
and  see if  the  results  Boost desires  manifested  after changing  to
forums.   My speculation  is  that  changing from  ML  to forums  mostly
reduces to the  preference/enthusiasm of the person  that is maintaining
that part of the infrastructure much more so than results it produces.

I've observed a similar conversation happening in a number of technical
mailing  lists  and suspect  there  is  something broader  happening  in
industry that results in these types of conversations, but not sure what
it is exactly.  Maybe just advancements in Github capabilities.


[*] I've not contributed to any review because I'm not expert enough C++
or in  the topic of  the library under review.   Often there a  dozen or
more  acronyms, special  cases, etc  that the  experts on  this list  do
realize  and  have the  ability  to  scrutinize.  I'm  appreciative  and
grateful  for the  quality  that  this ensures  and  learn  quite a  bit
following along, but  that doesn't make me qualified to  do a review and
in my mind, doing so would just be wasting other experts scarce time.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Re: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost
<[hidden email]> wrote:
> My suggestion  is....

Yeah mailing lists are nice for the monotonically decreasing set of
older engineers used to the anachronism but they are not in any way
shape or form attractive for bringing in new, young blood.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-06-29 04:49, René Ferdinand Rivera Morell via Boost wrote:

> On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost <
> [hidden email]> wrote:
>
>> The concrete items mentioned that have been known to inhibit
>> participation appear to be:
>> - Mailing lists
>> - Boost.Build
>>
>> Not sure what to do about the second.
>>
>
> It's easy.. Make it abundantly clear that a build system, *any* build
> system, is expected or required for review. And one way to do that is to
> *require* no build system for review. Because if your library can be
> reviewed easily without a build system it means the portability of your
> code is good. Anything else should be a red flag for reviewers.
>
>
> PS. I'll keep living the dream when we don't distribute any build system
> with our libraries. Or the alternate dream where we distribute with 5 or
> more alternate build system specifications.

Assuming the library requires separate compilation, a build system is
needed for the library to be usable. Reviewing and accepting a library
that is not usable makes no sense.

Furthermore, in order for users to be able to use Boost, they need a way
to build it, that is compile and install artifacts of every library in a
common place. There needs to be a common interface for doing this.
Currently, this is achieved by Boost.Build, so any new library has to
integrate with it. If it uses a different build system internally, it
must at least support being invoked from Boost.Build. Without this user
experience will be severely hampered.

I'm not insisting that Boost.Build should be that common user interface
for building Boost, but there must be one. I'm not attached to
Boost.Build specifically - any build system that is able to handle
building and testing Boost, including docs, would do. However,
personally I'm opposed to having mode than one build systems per
library, as that unnecessarily increases maintenance burden.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-06-29 08:40, Vinnie Falco via Boost wrote:
> On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost
> <[hidden email]> wrote:
>> My suggestion  is....
>
> Yeah mailing lists are nice for the monotonically decreasing set of
> older engineers used to the anachronism but they are not in any way
> shape or form attractive for bringing in new, young blood.

Hopefully, the young blood will mature one day and realize the
convenience of the "anachronisms".

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Re: Boost, not LEWG

Boost - Dev mailing list
On Mon, 29 Jun 2020 at 09:52, Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-06-29 08:40, Vinnie Falco via Boost wrote:
> > On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost
> > <[hidden email]> wrote:
> >> My suggestion  is....
> >
> > Yeah mailing lists are nice for the monotonically decreasing set of
> > older engineers used to the anachronism but they are not in any way
> > shape or form attractive for bringing in new, young blood.
>
> Hopefully, the young blood will mature one day and realize the
> convenience of the "anachronisms".
>


The mailing list is highly inconvenient, definitely a thing that should be
in the past. A forum would be awesome. A few quick reasons off the top of
my head to use a forum:

1) Better quoting of previous posts (thereby killing the top posting issue).
2) Quotes from multiple posters can be addressed in a single reply.
3) No lengthy corporate signatures in every post.
4) Easy to see from a high level what all the topics of discussion are. At
the moment there's a boost users list, a boost developers list. Think
there's one for Spirit. Is there one for UBLAS too? Not sure what others.
5) Clients can subscribe to particular messages and get notifications of
changes to those in their email (or when the return to the forum). This is
better then scanning through an email inbox.
6) We all have different email clients. Every one of us needs to do
configuration to mark the emails appropriately and move them to a
particular folder. Boost emails are interspersed with my personal emails.
Moving to a web-based forum will give us all our inboxes back.
7) Sometimes messages on the Boost list go to my email spam folders and
therefore easily missed. This wouldn't happen anymore.
8) Ability to do polls (e.g. should a proposed library be included in
Boost?).
9) Blocks of code will appear nicer assuming they're marked up.
10) Some email clients only allow threads up to x (e.g. 100) messages so
you get a different line in your inbox although it's the same thread.
11) Threads can be closed.
12) Messages can be edited/refined after posting.
13) Better navigation through lengthy threads because pagination comes in
to play.
14) Stickys available for FAQs.
15) Ability to put images in messages to show compilation time graphs, etc.

Pete



>
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Vinnie Falco via Boost
> Sent: 29 June 2020 06:40
> To: [hidden email] List <[hidden email]>
> Cc: Vinnie Falco <[hidden email]>
> Subject: Re: [boost] [OT] Re: Boost, not LEWG
>
> On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost <[hidden email]> wrote:
> > My suggestion  is....
>
> Yeah mailing lists are nice for the monotonically decreasing set of older engineers used to the
> anachronism but they are not in any way shape or form attractive for bringing in new, young blood.

As one no longer in the first flush of youth (and I suspect a target of this barb đŸ˜‰ ), I'm not sure that this is the most important issue.

We seem to have shifted to CVS, SVN and now GIT and GitHub a little ahead of the curve (and I note that GitHub gives you an email interface as well as a web one).

I suspect that 'If it ain't broke, don't fix it."  applies to the mailing list/forum issue.

I think that the key problem with reviews in finding people who are knowledgeable enough to make useful comments.  Often users are best-informed we can get.

Too many reviews are theoretical analyses, not based on any 'real-life' use that would expose strengths and weaknesses.

There has long been a chicken and egg issue, you don't get many users until a library is in Boost, and so you don't get much informed feedback.  I still favor some sort of 'Candidate' status, formalizing the current 'Acceptance subject to changes' status, but giving wider visibility on the Boost GitHub site.

Boost has spawned several standards, but also provided many libraries that are entirely unsuitable for standardization.  I hope this will continue.

Paul Bristow

PS I have always been impressed by the overwhelmingly politeness of interchanges on Boost and WG21 etc, in contrast to the internet in general.
I believe that Boost is also entirely gender and color-blind.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On Mon, Jun 29, 2020 at 2:16 AM Paul A Bristow via Boost <
[hidden email]> wrote:

> As one no longer in the first flush of youth (and I suspect a target of
> this barb đŸ˜‰ ), I'm not sure that this is the most important issue.
>

My point is that the technical discussions (including the formal reviews)
on the mailing list are a wonderful resource that casual observers have no
way to see because it is locked up behind a mailing list. Boost can't
leverage these discussions by linking to them in a news feed, highlighting
popular discussions, attaching flair based on their participation, and so
on and so forth. Imagine if StackOverflow was a mailing list instead.

Yes I realize that there are mirrors but that is not even close to the same
thing. The Boost organization has no editorial control over a mirror, and
it isn't even under a domain that has brand recognition.

Regards

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-06-29 12:13, Peter Barker via Boost wrote:
>
> The mailing list is highly inconvenient, definitely a thing that should be
> in the past. A forum would be awesome.

Not hoping to convert anyone, but still I'm going to answer a few points
below so that it becomes more evident that most of these points are
either solvable or not a problem.

> A few quick reasons off the top of
> my head to use a forum:
>
> 1) Better quoting of previous posts (thereby killing the top posting issue).

All email clients, including the GMail web interface, have a decent
quoting capability. Some clients (e.g. KMail) even color different
levels of quotation differently.

Top-posting is a cultural thing more than technical.

> 2) Quotes from multiple posters can be addressed in a single reply.

This is actually a bad thing to to do. When I'm looking though new
messages in a topic, I often don't read each message though just to see
if someone addressed or replied to me somewhere in the middle of his
post. So, don't merge multiple replies into one post, please.

> 3) No lengthy corporate signatures in every post.

Using corporate email for mailing lists is probably not the best idea,
unless you're participating on behalf of the company. However,
signatures are configurable and removable when posting a message. I
admit, this may be less convenient if you have to remove the signature
before posting.

> 4) Easy to see from a high level what all the topics of discussion are. At
> the moment there's a boost users list, a boost developers list. Think
> there's one for Spirit. Is there one for UBLAS too? Not sure what others.

I believe, the suggestion was to have multiple forums, in which case you
will have multiple lists of posts as well.

If you mean grouping messages in threads then every decent email client
has that capability.

> 5) Clients can subscribe to particular messages and get notifications of
> changes to those in their email (or when the return to the forum). This is
> better then scanning through an email inbox.

This is an advantage for casual one-time posters, I agree.

> 6) We all have different email clients. Every one of us needs to do
> configuration to mark the emails appropriately and move them to a
> particular folder. Boost emails are interspersed with my personal emails.
> Moving to a web-based forum will give us all our inboxes back.

Filtering is there for the rescue. I have 8 mailing lists in my mail, 5
of them are pretty active (dozens messages per day), each in its own
folder. That is not counting notifications from various platforms, like
GitHub and CIs, which are also nicely separated. All that took is to
configure GMail filters once when I subscribed to a list or platform. I
can't imagine how I could follow 8 different forums instead.

> 7) Sometimes messages on the Boost list go to my email spam folders and
> therefore easily missed. This wouldn't happen anymore.

Again, filters allow to mitigate this. GMail has "don't mark as spam"
checkbox.

> 8) Ability to do polls (e.g. should a proposed library be included in
> Boost?).

It's not clear to me that polling should be integrated with the
messaging system.

And Boost reviews are not polls anyway. A review must not only contain
accept/reject verdict. In fact, it may not contain one and only point
out various points about the library. The review manager makes an
informed decision about acceptance based on reviews, possibly in spite
of the accept/reject verdicts in them.

> 9) Blocks of code will appear nicer assuming they're marked up.

To this I would agree, but only assuming a decent markup is available in
the forum engine. In some forums I've seen the markup is terrible, to
the point it is easier to just paste the code as is.

And speaking of markup and formatting, some forums are too eager to
interpret the text as a markup or various smileys, which is unacceptable
for technical content. Plain text is the best media for technical
communication.

> 10) Some email clients only allow threads up to x (e.g. 100) messages so
> you get a different line in your inbox although it's the same thread.

Nothing to say here, other than maybe try another client, or request a
feature to remove the limit from the email client developers.

> 11) Threads can be closed.

Not a useful feature, IMHO. I don't remember a single time when I would
want to explicitly close a discussion. Someone may have a reason to
revive an old discussion, and there's nothing wrong with that.

> 12) Messages can be edited/refined after posting.

This one is debatable. On one hand, it is useful to be able to correct
mistakes noticed just after posting. However, editing or rewriting posts
after the discussion has moved on (i.e. after people have read and
reacted to your original message) is not right.

> 13) Better navigation through lengthy threads because pagination comes in
> to play.

I hate pagination. I hate having to click through pages seeking for the
one message I'm interested in or want to reply to. And I often do want
to respond to someone in the middle of the discussion, as I get an idea
some time after I read the post. This would be a major drawback for me.

In the mail client I can skim through message headers looking for a
particular date and author or use search without having to click through
pages.

> 14) Stickys available for FAQs.

This might be useful.

> 15) Ability to put images in messages to show compilation time graphs, etc.

I don't think this is useful in a technical forum like Boost, more like
a gimmick, but ok.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Vinnie Falco wrote:

> My point is that the technical discussions (including the formal reviews)
> on the mailing list are a wonderful resource that casual observers have no
> way to see because it is locked up behind a mailing list. Boost can't
> leverage these discussions by linking to them in a news feed, highlighting
> popular discussions, attaching flair based on their participation, and so
> on and so forth. Imagine if StackOverflow was a mailing list instead.

The purpose of this mailing list is to coordinate and aid Boost development,
not to be Stack Overflow. This is not something unique to Boost; most open
source projects use mailing lists for that. If you want Stack Overflow, you
know where to find it.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Vinnie Falco wrote:

> My point is that the technical discussions (including the formal reviews)
> on the mailing list are a wonderful resource that casual observers have no
> way to see because it is locked up behind a mailing list. Boost can't
> leverage these discussions by linking to them in a news feed, highlighting
> popular discussions, attaching flair based on their participation, and so
> on and so forth. Imagine if StackOverflow was a mailing list instead.
>
> Yes I realize that there are mirrors but that is not even close to the same
> thing. The Boost organization has no editorial control over a mirror, and
> it isn't even under a domain that has brand recognition.

The final phrase about the domain makes me wonder if you're unaware of
https://lists.boost.org/Archives/boost/ ; it is available to "casual observers",
could be linked to from anywhere, and has Boost "branding".  Or do you not
mean the Boost brand when you say "brand recognition"? - do you want a more
recognised brand like github or stackoverflow or google or something?


Regards, Phil.





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Jun 29, 2020 at 3:47 AM Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-06-29 04:49, René Ferdinand Rivera Morell via Boost wrote:
> > On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost <
> > [hidden email]> wrote:
> >
> >> The concrete items mentioned that have been known to inhibit
> >> participation appear to be:
> >> - Mailing lists
> >> - Boost.Build
> >>
> >> Not sure what to do about the second.
> >>
> >
> > It's easy.. Make it abundantly clear that a build system, *any* build
> > system, is expected or required for review. And one way to do that is to
> > *require* no build system for review. Because if your library can be
> > reviewed easily without a build system it means the portability of your
> > code is good. Anything else should be a red flag for reviewers.
> >
> >
> > PS. I'll keep living the dream when we don't distribute any build system
> > with our libraries. Or the alternate dream where we distribute with 5 or
> > more alternate build system specifications.
>
> Assuming the library requires separate compilation, a build system is
> needed for the library to be usable. Reviewing and accepting a library
> that is not usable makes no sense.
>

All users already have a build system. Most have it in the form of an IDE.
It should be trivial to add the library's source files to your own build
system for review purposes. If the library design makes that hard it should
be a red flag.


> Furthermore, in order for users to be able to use Boost, they need a way
> to build it, that is compile and install artifacts of every library in a
> common place. There needs to be a common interface for doing this.
> Currently, this is achieved by Boost.Build, so any new library has to
> integrate with it. If it uses a different build system internally, it
> must at least support being invoked from Boost.Build. Without this user
> experience will be severely hampered.
>

That can happen after acceptance. Expecting libraries to use B2, or any
particular build system, for review increases the barrier of entry.


> [snip]

However,
> personally I'm opposed to having mode than one build systems per
> library, as that unnecessarily increases maintenance burden.
>

Having more than one build system in your library reduces the friction for
users. Hence it increases the set of likely users. I think that's worth the
maintenance burden.

--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Jun 29, 2020 at 5:34 AM Phil Endecott via Boost
<[hidden email]> wrote:
> The final phrase about the domain makes me wonder if you're unaware of
> https://lists.boost.org/Archives/boost/ ; it is available to "casual observers",

I did not know about that, thanks. Yes by brand I mean "under boost.org."

Regards

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-06-29 15:37, René Ferdinand Rivera Morell wrote:
> On Mon, Jun 29, 2020 at 3:47 AM Andrey Semashev via Boost
> <[hidden email] <mailto:[hidden email]>> wrote:
>
> All users already have a build system. Most have it in the form of an
> IDE. It should be trivial to add the library's source files to your own
> build system for review purposes. If the library design makes that hard
> it should be a red flag.

Having the world compiled along with your application is one possible
use case, but certainly not the only one. Many of us prefer to build
external dependencies separately and only once instead of every time
with the application.

One point where putting external sources in your project doesn't work is
configure-time checks, which are implemented in the library build
system. I see nothing wrong with such checks, and don't consider them a
"red flag".

>     Furthermore, in order for users to be able to use Boost, they need a
>     way
>     to build it, that is compile and install artifacts of every library
>     in a
>     common place. There needs to be a common interface for doing this.
>     Currently, this is achieved by Boost.Build, so any new library has to
>     integrate with it. If it uses a different build system internally, it
>     must at least support being invoked from Boost.Build. Without this user
>     experience will be severely hampered.
>
>
> That can happen after acceptance. Expecting libraries to use B2, or any
> particular build system, for review increases the barrier of entry.

It prevents reviewers from trying out the library. It might also suggest
that the library have not been built or tested prior to the review.

>     [snip]
>
>     However,
>     personally I'm opposed to having mode than one build systems per
>     library, as that unnecessarily increases maintenance burden.
>
> Having more than one build system in your library reduces the friction
> for users. Hence it increases the set of likely users. I think that's
> worth the maintenance burden.

Well, let's just say I disagree.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On Mon, Jun 29, 2020 at 7:58 AM Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-06-29 15:37, René Ferdinand Rivera Morell wrote:
> > On Mon, Jun 29, 2020 at 3:47 AM Andrey Semashev via Boost
> > <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > All users already have a build system. Most have it in the form of an
> > IDE. It should be trivial to add the library's source files to your own
> > build system for review purposes. If the library design makes that hard
> > it should be a red flag.
>
> Having the world compiled along with your application is one possible
> use case, but certainly not the only one. Many of us prefer to build
> external dependencies separately and only once instead of every time
> with the application.
>

After *acceptance* use a package manager.


> One point where putting external sources in your project doesn't work is
> configure-time checks, which are implemented in the library build
> system. I see nothing wrong with such checks, and don't consider them a
> "red flag".
>

I see them as a red flag.


> >     Furthermore, in order for users to be able to use Boost, they need a
> >     way
> >     to build it, that is compile and install artifacts of every library
> >     in a
> >     common place. There needs to be a common interface for doing this.
> >     Currently, this is achieved by Boost.Build, so any new library has to
> >     integrate with it. If it uses a different build system internally, it
> >     must at least support being invoked from Boost.Build. Without this
> user
> >     experience will be severely hampered.
> >
> >
> > That can happen after acceptance. Expecting libraries to use B2, or any
> > particular build system, for review increases the barrier of entry.
>
> It prevents reviewers from trying out the library. It might also suggest
> that the library have not been built or tested prior to the review.
>

It would be rather unlikely for that to be the case given the preceding
history of a library before getting to the review stage.


> >     [snip]
> >
> >     However,
> >     personally I'm opposed to having mode than one build systems per
> >     library, as that unnecessarily increases maintenance burden.
> >
> > Having more than one build system in your library reduces the friction
> > for users. Hence it increases the set of likely users. I think that's
> > worth the maintenance burden.
>
> Well, let's just say I disagree.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Il lun 29 giu 2020, 11:16 Paul A Bristow via Boost <[hidden email]>
ha scritto:

>
> Boost has spawned several standards, but also provided many libraries that
> are entirely unsuitable for standardization.  I hope this will continue.
>
> Paul Bristow
>
> PS I have always been impressed by the overwhelmingly politeness of
> interchanges on Boost and WG21 etc, in contrast to the internet in general.
> I believe that Boost is also entirely gender and color-blind.
>


I am a long time boost user and subscriber to this mailing list, even if I
never authored a boost library. That said, since the topic is on the
relevance of boost for the future and how it is perceived, I take the
liberty to add my 2 cents, for what they are worth.

I may be oldish (I still feel young inside) and I see the points raised in
favour of more "modern" approaches but I think that *this specific* ml is
still working. I suspect that the reason is in no small part due to Paul's
observation re: politeness and the continued effort to argue on technical
merits.

This ml is without doubt the place where I have learnt and continue to
learn the most about c++ and software design in general.

The only inherent flaw in the "mailing list medium" is the difficulty of
tracking the subject changes in the headers, but I don't think that
switching to a forum or to a "social network" like stackoverflow would
change that. For me, I would probably not have the time to browse such a
platform (I fully acknowledge that if more people feel differently this
could be a net positive!).

In short: please continue with a rigorous review process, without relaxing
the standards! I promise that the next time that a library where I am not a
complete ignorant is proposed will try to add my review. It will surely be
short and not as deep as many of you are able to provide, but Boost has
excellent review managers who are able to make something of every
contribution.

Best,
Francesco

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
René Ferdinand Rivera Morell wrote:

> Expecting libraries to use B2, or any particular build system, for review
> increases the barrier of entry.

It does, and I consider this a feature. Writing a Jamfile or two is trivial
(if indeed your library is a bag of source files and it doesn't need to
f.ex. link to OpenSSL or detect AVX-512 at configure time.) Refusing to do
so is a deliberate slight.

Same would apply to CMake by the way; having a submodule-friendly
CMakeLists.txt should be a requirement, and will indeed also increase the
barrier of entry. So far, 0% of the libraries having a CMakeLists.txt file
have been usable as a submodule.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Jun 29, 2020 at 3:23 AM Vinnie Falco via Boost <
[hidden email]> wrote:

>
> On Mon, Jun 29, 2020 at 2:16 AM Paul A Bristow via Boost <
> [hidden email]> wrote:
>
> > As one no longer in the first flush of youth (and I suspect a target of
> > this barb ), I'm not sure that this is the most important issue.
>
> My point is that the technical discussions (including the formal reviews)
> on the mailing list are a wonderful resource that casual observers have no
> way to see because it is locked up behind a mailing list.

Nothing is locked, the discussion is public.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On the subject of the mailing list: because one needs to be "on" it to
participate, that makes it a better environment to conduct Boost reviews.
Imagine doing that in front of a stackoverflow-type audience. I'm convinced
that this would be contrary to the stated goal to keep the quality high.

Perhaps we can benefit from the extra traffic, but that is a separate issue.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [OT] Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 29/06/2020 22:30, Andrey Semashev wrote:
> Using corporate email for mailing lists is probably not the best idea,
> unless you're participating on behalf of the company. However,
> signatures are configurable and removable when posting a message. I
> admit, this may be less convenient if you have to remove the signature
> before posting.

Actually, corporate signatures aren't always removable.  Sometimes
they're added by the mail server rather than the mail client.

>> 4) Easy to see from a high level what all the topics of discussion
>> are. At
>> the moment there's a boost users list, a boost developers list. Think
>> there's one for Spirit. Is there one for UBLAS too? Not sure what others.
>
> I believe, the suggestion was to have multiple forums, in which case you
> will have multiple lists of posts as well.
>
> If you mean grouping messages in threads then every decent email client
> has that capability.

Speaking as one of the anachronistic old engineers, I prefer using
newsgroups (via gmane, creaky as it may be) over forums over mailing
lists, in that order.

Another group I frequently participated in recently retired a "real"
newsgroup server and switched over to a mailing list, and I ended up not
participating any further until after it was mirrored to gmane.

(And I'm currently reading this list via gmane as well.)

This isn't really any sort of philosophical issue; I just tend to forget
that web forums exist, so don't check them as often, whereas both email
and newsgroups are more in-your-face -- and I personally find the UX of
newsgroups to be preferable.

(Some people may regard "less in-your-face" as a feature, but I find it
means more messages build up between checks which makes it take longer
to catch up, increasing the likelihood of putting it off until you have
"more time" and then quickly becoming unmanageable.  Maybe that's just me.)

But any change, no matter which direction, is likely to dislodge some
people -- it's more a question of whether there'd be enough new people
attracted to warrant it.  (This happens with any kind of community.)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Gesendet: Montag, 29. Juni 2020 um 19:21 Uhr
> Von: "Emil Dotchevski via Boost" <[hidden email]>
> An: "Boost" <[hidden email]>
> Cc: "Emil Dotchevski" <[hidden email]>
> Betreff: Re: [boost] Boost, not LEWG
>
> On the subject of the mailing list: because one needs to be "on" it to
> participate, that makes it a better environment to conduct Boost reviews.
> Imagine doing that in front of a stackoverflow-type audience. I'm convinced
> that this would be contrary to the stated goal to keep the quality high.

Why are people equating forums with SO? Contrary to forums, extended discussions are frowned upon on SO, and contrary to SO, forums usually don't rate posts (although some have a like button). SO is a site for Q&A, forums are centered around discussions.

As someone who didn't grow up using mailing lists, I have to say I find them (and the archive) rather uncomfortable to use, so my guess is that this is to a large degree a matter of what you are used to and how much time you spend to setup your tools (kind of VI vs a gui text editor/IDE).

Best

Mike

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