Re: [boost] A bike shed (any colour will do) on greener grass...

Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-10-30 16:03:00

Le 30/10/13 14:07, Ahmed Charles a écrit :
>
>
>> Date: Sat, 19 Oct 2013 11:44:11 +0200
>> From: vicente.botet_at_[hidden]
>> To: boost_at_[hidden]
>> Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
>>
>> I recognize that I missed the date.
>>
>> BTW, from the contents of your messages I understand that you could not
>> be wrong never as you have always taken the time to analyze carefully
>> the contents of all the threads, inspected carefully the dates of the
>> each one of the post and in addition that your understanding of what
>> other can thing is always the good one.
>>
>> Note that your posts are much more confusing because you are pushing all
>> the authors to follow what you are doing without any respect for their
>> opinion.
>>
>> I would like to know who gave you the right to update the whole
>> repository without contacting each one of the authors (I was surely on
>> vacation when you got this right). Before been able to update the Boost
>> repository the people must know how the Boost community works. It seems
>> that you ignored how we work and in this sens I understand better now
>> why you were applying practice you use to use on other communities.
>>
>> I have send some replays to your posts and you are ignoring most of them.
> I've been reading the boost lists for years now and I almost never send mails to them because of a variety of factors, but most importantly, things almost never reach a reasonable conclusion or consensus. Actually adding value seems really hard in any thread that gets the attention of any number of people while not being focused on one or two people. Basically, asking a specific question of a maintainer often works cause it's almost like a two way conversation happening in public, but any thread which is unfocused in any way, is inevitably going to get derailed, often hilariously. (or why else would I read them, right?)
>
> Stephen's experience isn't unique and it's probably common, the primary difference is that he's actually pointing it out. His responses aren't ideal or perfect but given the complexity of most of the code in boost, one might well expect people on this list to understand how to search without mailing the list first.
>
> Boost reminds me of a corporation (guild) that I was part of in Eve Online, where the old members had done lots of glorious stuff in the past but no longer had the time or inclination to put into current pursuits, but at the same time, none of the new members had the standing in the group to take control and move it forward while the old guard also had an interest in maintaining some amount of control and former glory. Granted, Boost is different, but as far as analogies go, it really does seem eerily similar.
>
> Short of boost being forked by a group of energetic people interested in making massive changes, how exactly will it ever migrate to C++11/14 with the current ownership model where people have to contact ~100 library maintainers if they want to make changes across the entire project? If all I wanted to do was create a branch to work on C++11/14 work or anything like it, not only would it require touching ~100 git repos, I'd have to send ~100 emails and create ~100 trac tickets with patches and then manage ~100 different conversations with ~100 different people, across different countries, timezones, native languages, cultures, etc. How do you ever expect anyone to ever want to do that?
>
> If you ignore the political side of what Stephen is trying to do and just concentrate on the technical side, it's daunting in scope and he's been willing to do it in spite of no reasonably belief that progress would be made and with tons of resistance. So, perhaps he didn't follow the process and he should have gone about it differently. But I would argue that Boost should have a process for changes that are so massive that working with individual maintainers isn't feasible. Expecting someone to make progress doing what he wants to do while following the usual boost process is simply ridiculous. Note: I just noted STL's patches taking weeks/months to get applied and they only touched two files.
>
> I know what it's like to spend an entire day simply managing code changes, where they are and how they all fit together into the big picture in order to ensure progress in the face of external delays, like code reviews and testing. I'm pretty sure if I wasn't getting paid to do it, I wouldn't do that part of my job and that's basically what you are asking someone to do, only like 50 times worse.
>
>   		 	   		
>
Hi,

I recognize the Boost process is not well adapted to these kind of changes.
If you want to change the Boost process please make a concrete proposal 
that takes into consideration this use case to this list.

Best,
Vicente