Hi: Given that the boost vault has been down for quite a few months, where are all new bosot libraries going for review, in the boost vault-with a different url, or in the boost sandbox in the svn repository? Any help appreciated. Regards Sean.
https://github.com/boost-vault 2011/7/15 Sean Farrow <sean.farrow@seanfarrow.co.uk>
Hi: Given that the boost vault has been down for quite a few months, where are all new bosot libraries going for review, in the boost vault-with a different url, or in the boost sandbox in the svn repository? Any help appreciated. Regards Sean. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Fri Jul 15 2011, Sean Farrow <sean.farrow-AT-seanfarrow.co.uk> wrote:
Hi: Given that the boost vault has been down for quite a few months, where are all new bosot libraries going for review, in the boost vault-with a different url, or in the boost sandbox in the svn repository? Any help appreciated. Regards
Well, it's "back up" in a manner of speaking. Your old URLs will send you someplace below http://github.com/boost-vault. Redirection is far from perfect, but it usually puts you in the right neighborhood. However, it's not intended that you put your library there for review. Ideally, you should get your own github account and publish the library that way. -Dave -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 7/15/2011 3:33 PM, Dave Abrahams wrote:
on Fri Jul 15 2011, Sean Farrow<sean.farrow-AT-seanfarrow.co.uk> wrote:
Hi: Given that the boost vault has been down for quite a few months, where are all new bosot libraries going for review, in the boost vault-with a different url, or in the boost sandbox in the svn repository? Any help appreciated. Regards
Well, it's "back up" in a manner of speaking. Your old URLs will send you someplace below http://github.com/boost-vault. Redirection is far from perfect, but it usually puts you in the right neighborhood.
However, it's not intended that you put your library there for review. Ideally, you should get your own github account and publish the library that way.
Just wondering... When and how that decision made? When and how was it communicated? Has the documentation for library submission been changed to reflect this? Did I miss something from the steering committee? -- -- 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
on Fri Jul 15 2011, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
On 7/15/2011 3:33 PM, Dave Abrahams wrote:
on Fri Jul 15 2011, Sean Farrow<sean.farrow-AT-seanfarrow.co.uk> wrote:
Hi: Given that the boost vault has been down for quite a few months, where are all new bosot libraries going for review, in the boost vault-with a different url, or in the boost sandbox in the svn repository? Any help appreciated. Regards
Well, it's "back up" in a manner of speaking. Your old URLs will send you someplace below http://github.com/boost-vault. Redirection is far from perfect, but it usually puts you in the right neighborhood.
However, it's not intended that you put your library there for review. Ideally, you should get your own github account and publish the library that way.
Just wondering...
When and how that decision made?
Sorry, I realize that the way I phrased this could have led you to misunderstand me. The last two sentences above are not an official position, but my personal recommendation. BoostPro made the decision to discontinue hosting the vault for these reasons: * We've never been happy with the security implications * We have been saying for quite some time we wanted to discontinue it * It broke a few times and we spent resources fixing it * The last time it broke, we actually couldn't figure out what was wrong So there we were: the vault was down, and had been for some time. Supporting the vault had been costing us time, and there are many free services that could serve the same purpose, only much better. We further invested our resources in moving the vault's current contents to GitHub and setting up redirects so that the contents would remain accessible to the community. We only just got that job finished a couple of days ago. Boost is of course free to move the contents of those repositories wherever it sees fit, and to make whatever decision it wants about how to fill the vault's role in the future.
When and how was it communicated? Has the documentation for library submission been changed to reflect this?
Did I miss something from the steering committee?
Since there was no official decision from the steering committee, there was nothing to communicate. "What should we do about the vault contents and how should the documentation be changed" would be a fine topic to bring up here. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Since the subject has come up of the vault vs. the subversion sandbox vs. something else I'm bringing up the various related issues and some of the options I'm aware of. This post is in two parts that are partly related: a) what to do with the vault content? and b) should Boost look for other hosting resources? .. On 7/16/2011 8:03 PM, Dave Abrahams wrote:
on Fri Jul 15 2011, Rene Rivera<grafikrobot-AT-gmail.com> wrote:
On 7/15/2011 3:33 PM, Dave Abrahams wrote:
on Fri Jul 15 2011, Sean Farrow<sean.farrow-AT-seanfarrow.co.uk> wrote:
However, it's not intended that you put your library there for review. Ideally, you should get your own github account and publish the library that way.
Just wondering...
When and how that decision made?
Sorry, I realize that the way I phrased this could have led you to misunderstand me. The last two sentences above are not an official position, but my personal recommendation.
Got it.. I was a bit puzzled, is all.
BoostPro made the decision to discontinue hosting the vault for these reasons:
* We've never been happy with the security implications * We have been saying for quite some time we wanted to discontinue it * It broke a few times and we spent resources fixing it * The last time it broke, we actually couldn't figure out what was wrong
So there we were: the vault was down, and had been for some time.
Which all makes sense.. And I'm all for not using the outdated and not-really-secure software the vault was using.
Supporting the vault had been costing us time, and there are many free services that could serve the same purpose, only much better. We further invested our resources in moving the vault's current contents to GitHub and setting up redirects so that the contents would remain accessible to the community. We only just got that job finished a couple of days ago.
Which I guess is fine as a backup of what was there. Although the functionality is not the same. So I guess this is more of a transition until we figure out what else to do.
Boost is of course free to move the contents of those repositories wherever it sees fit, and to make whatever decision it wants about how to fill the vault's role in the future.
When and how was it communicated? Has the documentation for library submission been changed to reflect this?
Did I miss something from the steering committee?
Since there was no official decision from the steering committee, there was nothing to communicate. "What should we do about the vault contents and how should the documentation be changed" would be a fine topic to bring up here.
And hence I'm bringing it up.. (A) As I see it something like the project hosting of Github doesn't fit the bill of what the vault's intent was: To provide a really low barrier proposed project code sharing with enough features to determine interest in those projects. The features we wanted for the vault where: * Only requirement to post was user self-registration. * Minimally provide for archive uploads (and downloads). * Download counts, to determine interest. * Some form of descriptions for the posted files. Feature that I think we might also want in a better vault: * Some form of feedback for posted files. This is to capture the people that don't want to join the mailing lists (which I've run into many instances of this.. on IRC). * "Versioning" on the posted files. So that authors can post updates without loosing the download count history. * An expanded file/project description to attract downloads. * An RSS feed for people to watch a project's files. * Some form of topical tagging (instead of the hierarchical directory structure) of project/files. 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 don't know enough about Github to see if it can deliver on the above features, so I will leave that for others to comment on. But if I had to choose I would likely use the Google project hosting. It seems to have all the features (except for the tagging AFAICT) in a manner that is easy, and immediate, to operate. Plus of course all the additional features most open-source projects would want. If we abandon the vault we also have to make the choices as to whether to abandon the current sandbox also. The reasons we've had two different systems until now is that the sandbox provides the revision control that some prospective projects want (when they don't want to use some other project hosting). This aspect doesn't seem to me as important anymore as there are varied project hosting services available. Which wasn't the case when the sandbox started. So to me it seems to make sense to also abandon the sandbox in favor of a combined solution. (B) This also brings up the question of what to do about the state of the hosting provided by IU-OSL. As we've seen there have been various scalability issues that have resulted in limiting the functionality we wanted from the tools at hand. I'm not talking about the simple things like the removal of the trac svn code browsers but also: * The removal of on-demand expanding ZIP archives for Boost releases. Which made the updating of docs on releases much easier than dealing with the expanded set. But of course it also made the process for getting those docs harder. * The hard limit of svn/webserver request times. Which makes many operations fail (like a full clean checkout/update -- or even a larger than usual svn update). * Because of the ban on ZIPs, the additional requirements on testers to do svn checkouts. * The limits on some svn clients that do "frequent" server status checks. The limit being that they get banned from connecting to the Boost svn. AFAICT this means that the Ohloh service is no longer able to monitor the Boost code base (http://www.ohloh.net/p/boost/enlistments). There are likely others, but those are the ones I'm aware of at the moment. Even though I appreciate the hard work it takes to host something like Boost. It seems that we can be better served through some other hosting. I recently found another university providing the same kind of hosting services we currently get. But in this case hosting is what they do, as opposed to something they happen do on the side. They are the Oregon State University Open Source Lab <http://osuosl.org/>. And they host a rather distinguished list of OSS projects <http://osuosl.org/services/hosting/communities> like: Apache, Debian, Drupal, Eclipse, Fedora, RPM, Slackware, and more. To me it's looking more and more that our requirements for hosting are increasing rather than stabilizing. And hence it makes sense to move to a provider than can scale, instead of sticking with one that needs to cut back. Hopefully I haven't opened too many "cans-of-worms" with this. But it seems relevant to discuss this now, before doing too many other changes in related services and tools (i.e. ryppl, cmake, git, etc.). -- -- 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
Hi, On Sun, Jul 17, 2011 at 05:22, Rene Rivera <grafikrobot@gmail.com> wrote:
Which I guess is what Dave is suggesting above. I don't know enough about Github to see if it can deliver on the above features, so I will leave that for others to comment on. But if I had to choose I would likely use the Google project hosting.
For your information : Fundamentally, they offer the same services. There are just two important differences between those : 1. GitHub is oriented on "collaboration" (whatever it means) and provide additional tools to this goal compared to GCodeHosting. 2. GCH provide Subversion and Mercurial repositories while GitHub provides Git only repositories. Git & Mercurial can work together easily it seems and there are tools and extensions to those to help working with svn repositories too. My suggestions: a) choose a main "central" repository hosting service, say github b) maybe maintain copies of those repositories on a more private server (maybe osuosl?) c) when someone provides source code to be put in sandbox or vault, they should provide a repository address : that external repository could be anywhere, the vault/sandbox would only be a regularly updated clone of that. That way you get a "central" public vault/sandbox, an easy to setup and secure backup (independent from the hosting service) and developers can use whatever repository hosting they want too. The backup would be easy to setup assuming you're using decentralized control source like on GitHub (no choice there), making changes transactions between repositories easier. My 2 cents. By the way, may I ask why does the github vault repositories contain zips instead of content of the zip files? Joël Lamotte
On 7/17/2011 5:59 AM, Klaim - Joël Lamotte wrote:
Hi,
On Sun, Jul 17, 2011 at 05:22, Rene Rivera<grafikrobot@gmail.com> wrote:
Which I guess is what Dave is suggesting above. I don't know enough about Github to see if it can deliver on the above features, so I will leave that for others to comment on. But if I had to choose I would likely use the Google project hosting.
For your information :
Fundamentally, they offer the same services. There are just two important differences between those : 1. GitHub is oriented on "collaboration" (whatever it means) and provide additional tools to this goal compared to GCodeHosting.
It would be good to know what those additional tools/features are. And more apt, if they are things that authors would want or need.
2. GCH provide Subversion and Mercurial repositories while GitHub provides Git only repositories.
Correction; GCH provides Subversion, Mercurial, and Git <http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem>.
Git& Mercurial can work together easily it seems and there are tools and extensions to those to help working with svn repositories too.
My suggestions: a) choose a main "central" repository hosting service, say github b) maybe maintain copies of those repositories on a more private server (maybe osuosl?) c) when someone provides source code to be put in sandbox or vault, they should provide a repository address : that external repository could be anywhere, the vault/sandbox would only be a regularly updated clone of that.
That way you get a "central" public vault/sandbox, an easy to setup and secure backup (independent from the hosting service) and developers can use whatever repository hosting they want too.
Although that gives a similar result to the traditional vault, it has one significant drawback. It introduces a management layer for Boost for each proposed library/file. This is worse than both the old vault (self-registration) and sandbox (one-time moderator registration).
The backup would be easy to setup assuming you're using decentralized control source like on GitHub (no choice there), making changes transactions between repositories easier.
Not sure what you mean here. But backups are "easy" with most RCS. Since there's no need to worry about the revision part (as it's a straight copy not a merge).
By the way, may I ask why does the github vault repositories contain zips instead of content of the zip files?
Because it's a direct copy of what the old vault contained. Which was just people uploading ZIPs for others to get. -- -- 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
On Sun, Jul 17, 2011 at 14:36, Rene Rivera <grafikrobot@gmail.com> wrote:
It would be good to know what those additional tools/features are. And more apt, if they are things that authors would want or need.
I cannot help on this side as I'm mostly using GHC, but I think there are github power-users in the boost community who would love to help.
2. GCH provide Subversion and Mercurial repositories while GitHub
provides Git only repositories.
Correction; GCH provides Subversion, Mercurial, and Git < http://code.google.com/p/**support/wiki/**ChoosingAVersionControlSystem<http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem>
**.
That's news to me! Itwasn't the case when I setup my projects few months ago, thanks for pointing it.
Although that gives a similar result to the traditional vault, it has one significant drawback. It introduces a management layer for Boost for each proposed library/file. This is worse than both the old vault (self-registration) and sandbox (one-time moderator registration).
I don't understand what "management layer" you are talking about exactly? I was thinking like just a few scripts that regularly pull repositories changes would make the "management" automatic. Joël Lamotte
On 7/17/2011 7:50 AM, Klaim - Joël Lamotte wrote:
On Sun, Jul 17, 2011 at 14:36, Rene Rivera<grafikrobot@gmail.com> wrote:
Although that gives a similar result to the traditional vault, it has one significant drawback. It introduces a management layer for Boost for each proposed library/file. This is worse than both the old vault (self-registration) and sandbox (one-time moderator registration).
I don't understand what "management layer" you are talking about exactly? I was thinking like just a few scripts that regularly pull repositories changes would make the "management" automatic.
Ah, I see. Yes, if the copying of the could be scripted then it would be a single registration task. I.e. equivalent to the current sandbox. Which might be fairly easy if it's straightforward to get a snapshot of the code from the source RCS. This is starting to sound more like a "standard" library release aggregation process which could be extended to multiple levels all the up to releases -- Assuming we have all modular libraries. -- -- 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
On 7/16/2011 11:22 PM, Rene Rivera wrote: snipped...
If we abandon the vault we also have to make the choices as to whether to abandon the current sandbox also. The reasons we've had two different systems until now is that the sandbox provides the revision control that some prospective projects want (when they don't want to use some other project hosting). This aspect doesn't seem to me as important anymore as there are varied project hosting services available. Which wasn't the case when the sandbox started. So to me it seems to make sense to also abandon the sandbox in favor of a combined solution.
Boost should provide some sort of version control hosting for potential Boost libraries. The sandbox has served that situation well and makes it easy for library developers to test their library against a Boost release/tree, such as the Boost trunk. Abandoning the sandbox does not seem reasonable to me unless there is a better version control hosting solution.
on Sun Jul 17 2011, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
On 7/16/2011 11:22 PM, Rene Rivera wrote: snipped...
If we abandon the vault we also have to make the choices as to whether to abandon the current sandbox also. The reasons we've had two different systems until now is that the sandbox provides the revision control that some prospective projects want (when they don't want to use some other project hosting). This aspect doesn't seem to me as important anymore as there are varied project hosting services available. Which wasn't the case when the sandbox started. So to me it seems to make sense to also abandon the sandbox in favor of a combined solution.
Boost should provide some sort of version control hosting for potential Boost libraries. The sandbox has served that situation well and makes it easy for library developers to test their library against a Boost release/tree, such as the Boost trunk. Abandoning the sandbox does not seem reasonable to me unless there is a better version control hosting solution.
GitHub is better. Google Code is better. BitBucket is better. Indefero is better. Shall I go on? ;-) My point is, there's no reason for Boost to spend its resources or attention on this; there are plenty of professionally-run services giving it away for free. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 7/17/2011 1:55 PM, Dave Abrahams wrote:
on Sun Jul 17 2011, Edward Diener<eldiener-AT-tropicsoft.com> wrote:
On 7/16/2011 11:22 PM, Rene Rivera wrote: snipped...
If we abandon the vault we also have to make the choices as to whether to abandon the current sandbox also. The reasons we've had two different systems until now is that the sandbox provides the revision control that some prospective projects want (when they don't want to use some other project hosting). This aspect doesn't seem to me as important anymore as there are varied project hosting services available. Which wasn't the case when the sandbox started. So to me it seems to make sense to also abandon the sandbox in favor of a combined solution.
Boost should provide some sort of version control hosting for potential Boost libraries. The sandbox has served that situation well and makes it easy for library developers to test their library against a Boost release/tree, such as the Boost trunk. Abandoning the sandbox does not seem reasonable to me unless there is a better version control hosting solution.
GitHub is better. Google Code is better. BitBucket is better. Indefero is better. Shall I go on? ;-)
Hm.. Perhaps you should. Since I wasn't aware of some of those ;-) Goes to show how far project hosting has progressed... Far enough to loose track of what's available!
My point is, there's no reason for Boost to spend its resources or attention on this; there are plenty of professionally-run services giving it away for free.
Right; but there is one thing that the current sandbox provides.. Boost topical locality. All the code in there is specifically for Boost in some form. And hence it's a bit easier for visitors to find new things in it. Which is what was brought up in other posts.. Of trying to not do our own central hosting, yet keep a nice central "index" / "catalog" location. -- -- 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
On Sunday, July 17, 2011 02:16:09 PM Rene Rivera wrote:
On 7/17/2011 1:55 PM, Dave Abrahams wrote:
on Sun Jul 17 2011, Edward Diener<eldiener-AT-tropicsoft.com> wrote:
On 7/16/2011 11:22 PM, Rene Rivera wrote: snipped...
If we abandon the vault we also have to make the choices as to whether to abandon the current sandbox also. The reasons we've had two different systems until now is that the sandbox provides the revision control that some prospective projects want (when they don't want to use some other project hosting). This aspect doesn't seem to me as important anymore as there are varied project hosting services available. Which wasn't the case when the sandbox started. So to me it seems to make sense to also abandon the sandbox in favor of a combined solution.
Boost should provide some sort of version control hosting for potential Boost libraries. The sandbox has served that situation well and makes it easy for library developers to test their library against a Boost release/tree, such as the Boost trunk. Abandoning the sandbox does not seem reasonable to me unless there is a better version control hosting solution.
GitHub is better. Google Code is better. BitBucket is better. Indefero is better. Shall I go on? ;-)
Hm.. Perhaps you should. Since I wasn't aware of some of those ;-) Goes to show how far project hosting has progressed... Far enough to loose track of what's available!
The best thing about these hosting services is that they publish their software as open source. github and gitorious provide free access to their software running the service (I don't know of the others) ....
My point is, there's no reason for Boost to spend its resources or attention on this; there are plenty of professionally-run services giving it away for free.
Right; but there is one thing that the current sandbox provides.. Boost topical locality. All the code in there is specifically for Boost in some form. And hence it's a bit easier for visitors to find new things in it. Which is what was brought up in other posts.. Of trying to not do our own central hosting, yet keep a nice central "index" / "catalog" location.
... How about getting the software and host a boost like github/svnhub/mercurialhub whatever (provided we have the necessary ressources)?
On Mon, Jul 18, 2011 at 08:33, Thomas Heller <thom.heller@googlemail.com>wrote:
... How about getting the software and host a boost like github/svnhub/mercurialhub whatever (provided we have the necessary ressources)?
Something like Rhodecode? (http://rhodecode.org/) This one isn't ready to be used with any other kind of repo than mercurial/hg, even if it's promising (I'm using it for private repos). So I think you would have to choose between: 1. use mercurial only (I guess it's not a real option) 2. contribute to rhodecode or another similar software to complete it for boost community needs 3. write your own repo manager It looks like none of those options would likely be done in short term. Maybe public hosting services could be a short-term solution while efforts are being done for a boost-community-managed service. That said, it's not a suggestion, just an observation. By the way, if TRAC is kept as issue tracking tool, the current stable version (0.12) allow multiple repositories to be managed under the same project (but I didn't tried to add new repos yet). You can have several repositories of different repo softs. However, it's not meant to "manage repositories"... Some suggested to switch to Redmine so to provide complete informations : Redmine and Jira also allows several repositories for one project (and allows sub-projects too). But they are not meant to manage repositories, like TRAC, only reference them. Hope those informations helps. Joël Lamotte
on Mon Jul 18 2011, Klaim - Joël Lamotte <mjklaim-AT-gmail.com> wrote:
By the way, if TRAC is kept as issue tracking tool, the current stable version (0.12) allow multiple repositories to be managed under the same project (but I didn't tried to add new repos yet). You can have several repositories of different repo softs. However, it's not meant to "manage repositories"...
Yeah, and it doesn't create repositories, and it doesn't support multiple projects.
Some suggested to switch to Redmine so to provide complete informations : Redmine and Jira also allows several repositories for one project
Redmine currently supports one repository per project. However, you can add multiple sub-projects to any project and attach a repo to each one.
(and allows sub-projects too). But they are not meant to manage repositories, like TRAC, only reference them.
Right. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 7/18/2011 4:17 AM, Klaim - Joël Lamotte wrote:
On Mon, Jul 18, 2011 at 08:33, Thomas Heller<thom.heller@googlemail.com>wrote:
... How about getting the software and host a boost like github/svnhub/mercurialhub whatever (provided we have the necessary ressources)?
Something like Rhodecode? (http://rhodecode.org/) This one isn't ready to be used with any other kind of repo than mercurial/hg, even if it's promising (I'm using it for private repos).
So I think you would have to choose between: 1. use mercurial only (I guess it's not a real option) 2. contribute to rhodecode or another similar software to complete it for boost community needs 3. write your own repo manager
It looks like none of those options would likely be done in short term. Maybe public hosting services could be a short-term solution while efforts are being done for a boost-community-managed service. That said, it's not a suggestion, just an observation.
I think this is moving in the opposite direction. We want to have less management work, not more. So it seems like a big drawback, just so we can have a single libraries index/catalog. -- -- 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
on Mon Jul 18 2011, Thomas Heller <thom.heller-AT-googlemail.com> wrote:
The best thing about these hosting services is that they publish their software as open source. github and gitorious provide free access to their software running the service (I don't know of the others) ....
My point is, there's no reason for Boost to spend its resources or attention on this; there are plenty of professionally-run services giving it away for free.
Right; but there is one thing that the current sandbox provides.. Boost topical locality. All the code in there is specifically for Boost in some form. And hence it's a bit easier for visitors to find new things in it. Which is what was brought up in other posts.. Of trying to not do our own central hosting, yet keep a nice central "index" / "catalog" location.
... How about getting the software and host a boost like github/svnhub/mercurialhub whatever (provided we have the necessary ressources)?
I am strongly opposed to hosting anything that we can get someone else to host. System administration is a huge...I'd say "time-waster," but I know it isn't pure waste... let's say, time-spender. In technological terms, I don't want to be anyone's major customer unless we have very specialized needs. I want the problems we have to be the same ones the service's whole client base is having, so that pressure to get things fixed is not just from/for us. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sun Jul 17 2011, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
GitHub is better. Google Code is better. BitBucket is better. Indefero is better. Shall I go on? ;-)
Hm.. Perhaps you should. Since I wasn't aware of some of those ;-)
Well, those are the ones off the top of my head, but I'm sure that if you dig (read: google) around you'll find others in a snap.
My point is, there's no reason for Boost to spend its resources or attention on this; there are plenty of professionally-run services giving it away for free.
Right; but there is one thing that the current sandbox provides.. Boost topical locality. All the code in there is specifically for Boost in some form. And hence it's a bit easier for visitors to find new things in it. Which is what was brought up in other posts.. Of trying to not do our own central hosting, yet keep a nice central "index" / "catalog" location.
Yes. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sat Jul 16 2011, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Supporting the vault had been costing us time, and there are many free services that could serve the same purpose, only much better. We further invested our resources in moving the vault's current contents to GitHub and setting up redirects so that the contents would remain accessible to the community. We only just got that job finished a couple of days ago.
Which I guess is fine as a backup of what was there. Although the functionality is not the same. So I guess this is more of a transition until we figure out what else to do.
Right.
As I see it something like the project hosting of Github doesn't fit the bill of what the vault's intent was: To provide a really low barrier proposed project code sharing with enough features to determine interest in those projects. The features we wanted for the vault where:
* 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.
* Minimally provide for archive uploads (and downloads).
You can check anything you want into a GitHub repository, including an archive. The same goes for most other free code hosting services. Most also allow me to download an archived snapshot of the repository, which I think covers the archive download requirement.
* Download counts, to determine interest.
Meh. Did anyone actually use that feature of the vault?
* Some form of descriptions for the posted files.
README.txt/.asciidoc/.markdown/.rst/... Also, GitHub wikis. 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. 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. 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 they provide "code review," what they really provide is "diff review," which makes it much less convenient than it should be to review the actual contents of a file without regard to its history. In fact, the only tool I know of that provides "real" code review (as opposed to diff review) is the Redmine code review plugin. [Coming back here, I see that google code lets me put comments on files]. Unfortunately, that's something we'd have to host ourselves and more importantly there would have to be a way for people to register new projects and create repositories without moderation—a role I feel is much better served by a public repo hosting service. I've bothered the GitHub people about this several times... *takes a detour to do that again*
Feature that I think we might also want in a better vault:
* Some form of feedback for posted files. This is to capture the people that don't want to join the mailing lists (which I've run into many instances of this.. on IRC).
+1, as I note above.
* "Versioning" on the posted files. So that authors can post updates without loosing the download count history.
+1, thus a repo
* An expanded file/project description to attract downloads.
README.*, wiki, ...
* 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.
* 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.
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.
I don't know enough about Github to see if it can deliver on the above features, so I will leave that for others to comment on. But if I had to choose I would likely use the Google project hosting. It seems to have all the features (except for the tagging AFAICT) in a manner that is easy, and immediate, to operate. Plus of course all the additional features most open-source projects would want.
*checks out google code* Well Google Code does have the ability to review files rather than diffs... It's been a while since I've looked, and I have to say I'm impressed... but I just tried adding some review commentary (as a different user) to a project I started and received no notification, and it didn't turn into an issue/ticket either, as it would on GitHub. 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.
If we abandon the vault we also have to make the choices as to whether to abandon the current sandbox also. The reasons we've had two different systems until now is that the sandbox provides the revision control that some prospective projects want (when they don't want to use some other project hosting). This aspect doesn't seem to me as important anymore as there are varied project hosting services available. Which wasn't the case when the sandbox started. So to me it seems to make sense to also abandon the sandbox in favor of a combined solution.
Agreed.
(B)
This also brings up the question of what to do about the state of the hosting provided by IU-OSL. As we've seen there have been various scalability issues that have resulted in limiting the functionality we wanted from the tools at hand.
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.
There are likely others, but those are the ones I'm aware of at the moment. Even though I appreciate the hard work it takes to host something like Boost. It seems that we can be better served through some other hosting. I recently found another university providing the same kind of hosting services we currently get. But in this case hosting is what they do, as opposed to something they happen do on the side. They are the Oregon State University Open Source Lab <http://osuosl.org/>. And they host a rather distinguished list of OSS projects <http://osuosl.org/services/hosting/communities> like: Apache, Debian, Drupal, Eclipse, Fedora, RPM, Slackware, and more. To me it's looking more and more that our requirements for hosting are increasing rather than stabilizing. And hence it makes sense to move to a provider than can scale, instead of sticking with one that needs to cut back.
Whoa, definitely. Is that something we can get for free?
Hopefully I haven't opened too many "cans-of-worms" with this. But it seems relevant to discuss this now, before doing too many other changes in related services and tools (i.e. ryppl, cmake, git, etc.).
Jah! Thanks for bringing it up! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sun Jul 17 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:
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.
There are likely others, but those are the ones I'm aware of at the moment. Even though I appreciate the hard work it takes to host something like Boost. It seems that we can be better served through some other hosting. I recently found another university providing the same kind of hosting services we currently get. But in this case hosting is what they do, as opposed to something they happen do on the side. They are the Oregon State University Open Source Lab <http://osuosl.org/>. And they host a rather distinguished list of OSS projects <http://osuosl.org/services/hosting/communities> like: Apache, Debian, Drupal, Eclipse, Fedora, RPM, Slackware, and more. To me it's looking more and more that our requirements for hosting are increasing rather than stabilizing. And hence it makes sense to move to a provider than can scale, instead of sticking with one that needs to cut back.
Whoa, definitely. Is that something we can get for free?
Just looked into this a bit myself. http://osuosl.org/services/hosting/details sounds *awesome*. I'm going to inquire as to whether they would host us. Can't hurt to ask! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sun, Jul 17, 2011 at 2:34 PM, Dave Abrahams <dave@boostpro.com> wrote:
Just looked into this a bit myself. http://osuosl.org/services/hosting/details sounds *awesome*. I'm going to inquire as to whether they would host us. Can't hurt to ask!
Yes, interesting for sure. --Beman
[Somehow forgot to send this to the list, I guess] on Sun Jul 17 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:
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.
There are likely others, but those are the ones I'm aware of at the moment. Even though I appreciate the hard work it takes to host something like Boost. It seems that we can be better served through some other hosting. I recently found another university providing the same kind of hosting services we currently get. But in this case hosting is what they do, as opposed to something they happen do on the side. They are the Oregon State University Open Source Lab <http://osuosl.org/>. And they host a rather distinguished list of OSS projects <http://osuosl.org/services/hosting/communities> like: Apache, Debian, Drupal, Eclipse, Fedora, RPM, Slackware, and more. To me it's looking more and more that our requirements for hosting are increasing rather than stabilizing. And hence it makes sense to move to a provider than can scale, instead of sticking with one that needs to cut back.
Whoa, definitely. Is that something we can get for free?
Just looked into this a bit myself. http://osuosl.org/services/hosting/details sounds *awesome*. I'm going to inquire as to whether they would host us. Can't hurt to ask!
Well, the response was very positive, and they have resources for build slaves. They've asked us for a few pieces of information: * Will we need them to host our SVN in the near term? I think we should say yes. * What is our estimated bandwidth usage? I'm not sure how to find out. DongInn, do you have that information? I guess a significant part of our bandwidth needs are being handled by SourceForge. I can see some information, e.g. at http://sourceforge.net/projects/boost/files/boost-binaries/stats/timeline, but I'm a bit at a loss concerning how to turn that into an aggregate number. * "In general how much disk space and RAM do we think we'll need?" I know, this is a tough one. I think it might be possible to come up with a number that doesn't include a projection for build slaves. But how? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Thu Jul 21 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:
I guess a significant part of our bandwidth needs are being handled by SourceForge. I can see some information, e.g. at http://sourceforge.net/projects/boost/files/boost-binaries/stats/timeline, but I'm a bit at a loss concerning how to turn that into an aggregate number.
Waiting on a reply from SF support: https://sourceforge.net/apps/trac/sourceforge/ticket/20849 -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 7/21/2011 9:16 PM, Dave Abrahams wrote:
[Somehow forgot to send this to the list, I guess]
Well, the response was very positive, and they have resources for build slaves. They've asked us for a few pieces of information:
* Will we need them to host our SVN in the near term?
I think we should say yes.
Definitely yes. And likely any other SCM/RCS in the future as we want at minimum a central repo (even if all it does it mirror other external repos).
* What is our estimated bandwidth usage?
I'm not sure how to find out. DongInn, do you have that information?
I guess a significant part of our bandwidth needs are being handled by SourceForge. I can see some information, e.g. at http://sourceforge.net/projects/boost/files/boost-binaries/stats/timeline, but I'm a bit at a loss concerning how to turn that into an aggregate number.
Another significant part would be the website, or more accurately the docs on the web site. The server used to keep a detailed usage log that we could get the info from it. I'll check if that's still around.. OK checked, they are still being kept. It will take some time to process them to get a bandwidth number though. Unless DongInn already has access to some web server stats.
* "In general how much disk space and RAM do we think we'll need?"
I know, this is a tough one. I think it might be possible to come up with a number that doesn't include a projection for build slaves. But how?
Web & SVN disk space is easy to come up with.. And I'm doing that now. Not sure about email server, and trac disk space though. The disk space for build slaves would of course depend on which slaves we want to run. At minimum I would think we might want to take over the trunk/release documentation building. Not sure if we want to add testing build slaves (especially since it means more management). OK, here's the current disk space I can easily find: -bash-3.00# du -ks www.boost.org/ 6140452 www.boost.org/ bash-3.00# du -ks /home/subversion/boost/ 2379564 /home/subversion/boost/ bash-3.00# du -ks /home/mailman-archives/ 3359692 /home/mailman-archives/ bash-3.00# du -ks /home/trac/boost/ 146896 /home/trac/boost/ bash-3.00# du -ks /home/www/beta.boost.org/ 37616 /home/www/beta.boost.org/ bash-3.00# du -ks /home/www/lists.boost.org/ 716 /home/www/lists.boost.org/ bash-3.00# du -ks /home/www/svn.boost.org/ 100 /home/www/svn.boost.org/ bash-3.00# du -ks /home/www/wiki.boost.org/ 8 /home/www/wiki.boost.org/ bash-3.00# du -ks /home/www/www2.boost.org/ 438832 /home/www/www2.boost.org/ Which boils down to: 12,503,876K == 12G -- Of course that doesn't include the OS, server software installations, release downloads (if we move those from SF), continuing growth in documentation, and growth in the SCM repo. But if we go back to ZIP archives for docs, and eventually move to new cloud based testing results the space usage would go down dramatically (most of the www.boost.org above is that). The RAM question is somewhat harder to answer. But since doing compilations (for the doc build slave), running python (i.e. trac), and the likely larger than usual SVN usage we might want to go for a "as much as we can afford" goal. And for comparison, the current server has 4G-RAM (8G virtual) and just about all of the physical RAM is used up. But the large use might be because of the large, although mostly idle, number of Apache prefork instances around. -- -- 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
On 7/25/2011 4:10 PM, Rene Rivera wrote:
Which boils down to: 12,503,876K == 12G -- Of course that doesn't include the OS, server software installations, release downloads (if we move those from SF)
PS. Just realized that release downloads wouldn't impact as they would go to the ftp mirror service they have. PPS. Got a number on the FTP upload space for the testers. It's currently at 780M. So add another Gig to the disk usage. For a total of 13G. -- -- 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
On 7/25/2011 4:35 PM, Rene Rivera wrote:
On 7/25/2011 4:10 PM, Rene Rivera wrote:
Which boils down to: 12,503,876K == 12G -- Of course that doesn't include the OS, server software installations, release downloads (if we move those from SF)
PS. Just realized that release downloads wouldn't impact as they would go to the ftp mirror service they have.
Which leaves the rest of the web server bandwidth.. So here's the last set of stats on that: total_size = 399009.945307 (MB) 389.658150 (GB) 398996.67 (MB) / 243393.17 (MB) /svn 243393.13 (MB) /svn/boost 242306.02 (MB) /svn/boost/!svn 241075.34 (MB) /svn/boost/!svn/vcc 241075.34 (MB) /svn/boost/!svn/vcc/default 77049.48 (MB) /doc 76330.54 (MB) /doc/libs 30113.00 (MB) /style-v2 29879.38 (MB) /style-v2/css_0 23037.05 (MB) /style-v2/css_0/theme_grass 22542.99 (MB) /doc/libs/1_46_1 21567.61 (MB) /style-v2/css_0/theme_grass/header-fg.png 18160.38 (MB) /development 18057.25 (MB) /doc/libs/1_47_0 16714.77 (MB) /development/snapshot.php 11241.27 (MB) /development/snapshot.php/tags 11209.77 (MB) /development/snapshot.php/tags/release 11115.28 (MB) /development/snapshot.php/tags/release/Boost_1_46_0 That's for the past 4 weeks of traffic to all the various *.boost.org sites. I.e. as is obvious from above, it includes the subversion traffic. There where approximately 13.75 million HTTP hits in the above (from a 3.25GB log file). This does not include bandwidth overheads, like hits that don't return actual web page data back to clients. So we might want to add 10% on top of the 390GB/month. But this does include SPAM/HACK traffic. Note: The "/" entry is slightly less because of the hack traffic that tend to take the form of include URIs. -- -- 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
From: "Dave Abrahams" <dave@boostpro.com>
* Download counts, to determine interest.
Meh. Did anyone actually use that feature of the vault?
I did. It was such a motivation boost. This single point made in my eyes the vault useful. When you bring a new library, you don't really know whether it generates any interest, and this during months, usually until the review. If you want to attract people not known on this list, keep this feature, anyhow. Christophe
On Sun, Jul 17, 2011 at 12:43 PM, Christophe Henry <christophe.j.henry@googlemail.com> wrote:
From: "Dave Abrahams" <dave@boostpro.com>
* Download counts, to determine interest.
Meh. Did anyone actually use that feature of the vault?
I did. It was such a motivation boost. This single point made in my eyes the vault useful. When you bring a new library, you don't really know whether it generates any interest, and this during months, usually until the review.
If you want to attract people not known on this list, keep this feature, anyhow.
It isn't "download counts" per se, but github for instance tracks the number of forks/followers, etc., in case you're keeping score in the reputation game. For instance, with my 5 followers (https://github.com/straszheim) I am 23.8% as cool as Dave Abrahams, with 21 (https://github.com/dabrahams). There is plenty more detail in there, for instance a nifty "impact" graph https://github.com/straszheim/ecto/graphs/impact -t
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
On Sunday, July 17, 2011 03:05:40 PM Rene Rivera wrote:
On 7/17/2011 11:48 AM, Dave Abrahams wrote:
on Sat Jul 16 2011, Rene Rivera<grafikrobot-AT-gmail.com> wrote: 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.
FWIW, github lets you checkout and commit through svn: https://github.com/blog/626-announcing-svn-support and https://github.com/blog/644-subversion-write-support
on Mon Jul 18 2011, Thomas Heller <thom.heller-AT-googlemail.com> wrote:
On Sunday, July 17, 2011 03:05:40 PM Rene Rivera wrote:
On 7/17/2011 11:48 AM, Dave Abrahams wrote:
on Sat Jul 16 2011, Rene Rivera<grafikrobot-AT-gmail.com> wrote: 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.
FWIW, github lets you checkout and commit through svn: https://github.com/blog/626-announcing-svn-support and https://github.com/blog/644-subversion-write-support
Oh, yeah, I forgot about that! That alone is enough to make me comfortable with GitHub as a solution. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 7/18/2011 8:24 PM, Dave Abrahams wrote:
on Mon Jul 18 2011, Thomas Heller<thom.heller-AT-googlemail.com> wrote:
On Sunday, July 17, 2011 03:05:40 PM Rene Rivera wrote:
On 7/17/2011 11:48 AM, Dave Abrahams wrote:
on Sat Jul 16 2011, Rene Rivera<grafikrobot-AT-gmail.com> wrote: 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.
FWIW, github lets you checkout and commit through svn: https://github.com/blog/626-announcing-svn-support and https://github.com/blog/644-subversion-write-support
Oh, yeah, I forgot about that! That alone is enough to make me comfortable with GitHub as a solution.
Except that wasn't it mentioned some time ago that even though Github says it's "beta".. It's actually more like "alpha" ? -- -- 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
On 17 July 2011 02:03, Dave Abrahams <dave@boostpro.com> wrote:
Since there was no official decision from the steering committee, there was nothing to communicate.
A short notice that the vault was moved would have been helpful. The link to the vault is currently broken on the site. I don't read every thread and could have quite easily overlooked this one, but I wouldn't overlook an email with the subject 'vault has moved'.
on Sun Jul 17 2011, Daniel James <dnljms-AT-gmail.com> wrote:
On 17 July 2011 02:03, Dave Abrahams <dave@boostpro.com> wrote:
Since there was no official decision from the steering committee, there was nothing to communicate.
A short notice that the vault was moved would have been helpful. The link to the vault is currently broken on the site. I don't read every thread and could have quite easily overlooked this one, but I wouldn't overlook an email with the subject 'vault has moved'.
Had you not noticed this thread, I would have done that soon enough. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (11)
-
Beman Dawes -
Christophe Henry -
Daniel James -
Dave Abrahams -
Denis Shevchenko -
Edward Diener -
Klaim - Joël Lamotte -
Rene Rivera -
Sean Farrow -
Thomas Heller -
Troy Straszheim