Prelude: The world needs ubiquitous Internet service on the cheap, because there are parts of the world where the Internet isn't as accessible. Or... I should really stop engaging in discussions around holiday times so that I don't miss out on the conversation. ;) That said, please see in-lined below. On Wed, Dec 29, 2010 at 2:41 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 12/28/2010 9:56 PM, Dean Michael Berris wrote:
Actually, I'd +2 if you said a review should be open until the library gets into the main distribution. And even after that, reviewing the quality of the library should be on-going and shouldn't stop at the point of inclusion into Boost. ;)
If a review, as it sometimes happens, determines that a library does not qualify for Boost but if some things were improved it might, I would agree with you that a review could be ongoing if the developer of the library is committed to maklng changes that would improve it. But I do not see the advantage of keeping reviews open until the library is accepted, especially with libraries deemed not of a high enough quality for Boost. OTOH nothing keeps a developer from making changes in his library and re-submitting it for inclusion into Boost again.
Well, there's the rub. Take what I said in the context of collaborative development instead of the current way of getting libraries into Boost. My issue with the status quo is that the barrier to entry for a library (and thus a contributor) is really high especially because of this practice of not letting others pitch into the work that goes into writing a library. As a case in point, I started the implementation of a bloom filter -- it's in the sandbox now, is functional, and some people have already contributed to the discussion on the development of the library. Back then there were people saying something about changing the implementation to do this, or the interface to be like that, etc. -- I pretty much dropped the development of that library mostly because I found that the suggestions would have been better in the form of patches. It is way easier to tell someone "you should do it another way" instead of actually showing what should be done with code -- and at the time I was interested in finishing the implementation, there were too many people saying "do this", or "do that" instead of sending me patches. Now what would have been a better process IMO would be something like the following: 1. Someone (in this case, I) show the community that "hey, I have this idea for a library that would be cool to include in Boost" -- this means it's in Github and people can actually get it 2. Those that would have wanted to contribute, would, instead of just expressing interest, would actually fork the repo and then implement their contributions in their own repositories, either submit their changes to me and we can all be co-authors of the library, or just gut it and tell everyone that here's a better way of doing it, based on what I've already done (or not). 3. In the process of the library being developed, a review can be posted by anyone at any given time which would count as a personal vote for/against the inclusion of the library. 4. Once there are enough "yes" votes, the library can then be scheduled for inclusion by the release managers -- this means, release managers would typically either pull, or use something like a git submodule to manage the libraries to be packaged up. On-going development of the library can follow that model and the "review" becomes more a regular part of daily things that happen on the developer's mailing list. The "management" of the review could be as simple as setting up a Wordpress Poll or something similar to get an actual "vote" from the members of the community -- not in an anonymous manner of course. This process is nothing like the status quo, and is actually a more encouraging model that allows people to get involved with minimal effort required.
As far as determining the quality of a library on an ongoing basis, anybody can currently suggest changes and new features. But I do not believe the developer should have to meet those new specs. OTOH I see nothing wrong with someone forking the library on his own and producing a second, very similar implementation with features he may deem necessary added, updated, or changed, and submitting that to Boost. This has already been done in some cases, such as signals and signals2, so why should not someone feel that it can be done elsewhere with another library.
Sure, but that doesn't make the process collaborative -- which is actually my main "beef" with the current way things are going. And, even if someone were to re-write a signals implementation, there's no need to actually fork it as a separate project as it could very well just be an evolution of the implementation and just get the contribution in as part of the normal process. Then, the release managers just make a determination of whether to actually get a certain version of the signals implementation from one repo, or get another from another repo. I hope this makes sense. :) PS. If you think about how the stock market indexes work, there's only a handful of people who choose which listed stock gets to be part of an index. The S&P 500 is managed by Standard & Poor who rate stocks according to their performance, suitability, capitalization, etc. and just list which of these stocks are part of the index. Boost can follow this model and have release managers -- in behalf of a larger community -- actually picking libraries which become part of the main distribution, and libraries that want to be listed follow a process similar to what the SEC requires companies that want to list on the NYSE or NASDAQ (of course with less red tape and bureaucracy ;)). That's the crux of the model I've wanted to convey, but apparently I needed to sleep on it a little more to get that analogy out. :D -- Dean Michael Berris about.me/deanberris