On 7/17/2011 11:48 AM, Dave Abrahams wrote:
on Sat Jul 16 2011, Rene Rivera<grafikrobot-AT-gmail.com> wrote:
* Only requirement to post was user self-registration.
Getting files up on GitHub requires git. I realize there isn't universal agreement for this point of view, but I think Boost should switch to Git. Moreover, I think Boost /will/ switch to Git. But until that's settled, it doesn't make sense for us to mandate that people host their submissions on GitHub.
I'm more of a "let me use whatever I want" person ;-) And I know there are a group of Boost devs that vary from "don't like" through "detest" and up to "hate" git. And to be honest I'm personally some place between "don't like" and "detest". So for that, and other reasons, I prefer to strongly consider solutions that allow flexibility in tools. So I would suggest the idea of providing "minimal requirements" to evaluate solutions. And requiring that people use a service that provides the minimal requirements. And obviously one requirement would be that we can easily integrate it into the rest of the Boost process as needed.
* Download counts, to determine interest.
Meh. Did anyone actually use that feature of the vault?
Weirdly I used to pay attention to those, but in the inverse of the expected. If a library came up for review that had lower downloads I would consider spending time to review to help out the person with the idea that it would likely get few reviews. And conversely if a lib had many downloads I would be OK with skipping it for review with the understanding that others would review it.
While the vault served some of the requirements on paper, and it presented a fairly low barrier for submitters, I found it inconvenient as a reviewer to have to pull down and unbundle an archive just to get a quick sense of whether I was interested at all in a library. It was just enough inconvenience to keep me from participating in any reviews over the past few years.
Yes, I had the same experience with downloading archives. It was always easier to update from an svn repo, i.e. the sandbox, or browse things on-line.
The priority should be on convenience for reviewers rather than for submitters, as there are hopefully many more of the former than the latter. As a reviewer, I really want to be able to review all of the code and documentation on the web. I'd also like the source to be presented in a SCM repository to ease integration of review commentary, etc. For me, this all points toward using a public repo hosting service like GitHub.
+1; In a dream world there would be a project hosting service that would allow many types of SCM clients to get the code regardless of what the author used to put the code in with.
I'd also like to be able to insert review commentary on specific lines of code and documentation through that interface. This is one area where almost all of the public SCM hosting options are weak: even if [...]
I think that we won't find a "perfect" solution, as usual.
* An RSS feed for people to watch a project's files.
Github has a nice little "watch" button. I don't think it delivers RSS, but then, I never really took to RSS as a way of keeping track of things changing. I wonder how many others like me are out there.
You might be in the minority ;-) RSS is how I manage to keep up with anything. If it wasn't for the Google RSS aggregator/reader I would feel like I was living under a rock.
* Some form of topical tagging (instead of the hierarchical directory structure) of project/files.
Hmm. Not sure what you have in mind here. However, it does bring up the point that once you go with a public repo hosting service and everyone gets his/her own reop, there's no "central directory" of everything that's been posted.
A central index/catalog is one aspect of what I'm talking about. Another is the ability to clearly say what areas your library covers. As we've had in the library list that puts them in multiple categories. I looked at Google Code a bit more and they have "labels". For example here's a list of the projects that refer to "Boost" <http://tinyurl.com/3zzhuyz> <http://code.google.com/hosting/search?q=label%3ABoost&projectsearch=Search+projects>. Or the ones about Boost GUIs <http://tinyurl.com/3tfnf2z> ;-)
Of course the other choice in all of this is to abandon providing a vault service and leave it up to individuals to figure out some other way to post their files. Which I guess is what Dave is suggesting above.
I think there's a position in between those: we recommend a few options.
+1, I think that's where I'm headed also. [...]
In fact, I can't even see the comments added by another user. Only patch suggestions seem to result in issues, and those are not very helpful when I click through to them. So, no service is perfect I guess.
See my comment about perfection above :-)
(B)
Yeah, the idea of spending some money (which we've earned through BoostCon) on our own host is one of the items on the steering committee's agenda.
I know you probably have an agenda in your head.. But perhaps putting an evolving agenda in some public place would be beneficial. Especially to get people to suggest things the committee might want to consider.
side. They are the Oregon State University Open Source Lab <http://osuosl.org/>. And they host a rather distinguished list of OSS
Whoa, definitely. Is that something we can get for free?
Not really sure about free, but it's not out of the question if I understand their goals accurately. They to mention getting some form of contributions from the projects but it seems that it's both actual cash and some times plain mutual benefit exchange. -- -- 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