[gsoc] Getting started with a repository (Was: Re: Live read-only GIT mirrors of Boost trunk SVN)
Following on from an earlier discussion... On 4 May 2013 20:00, Stefan Seefeld <stefan@seefeld.name> wrote:
On 05/04/2013 01:25 PM, Dave Abrahams wrote:
on Sat May 04 2013, Stefan Seefeld <stefan-AT-seefeld.name> wrote:
it would be great if the sandbox could be converted quickly, so GSoC students can use it ? We don't expect anyone to commit to https://github.com/boostorg/sandbox once the transition is complete. In fact, it would be good to stop now. Instead, people should use individual Git repositories.
OK, that makes sense. So sanbox projects become entirely independent with the only dependency being some upstream boost version (which may correspond to either a release or a development version).
So, students can assume that users have boost installed on their machine in a standard location, and can set up a separate git repository for their project. Great. I remember there used to be a template in the sandbox for getting started; all I see right now is this: http://svn.boost.org/svn/boost/sandbox/template_under_construction/ It looks like it's the right kind of thing, but is this still under_construction (cc'ing Stjepan)? It seems to produce a basic set of directories, Jamfiles, etc. when following these steps: svn co http://svn.boost.org/svn/boost/sandbox/template_under_construction/ cd template_under_construction python file_template.py sandbox # Answer some question prompts
It would be great if they didn't need to learn a thousand tools before
being able to focus on the project itself, and so having a well-defined and -documented process to set things up and get started would be very helpful. I don't know what you mean here, sorry.
Never mind. I was thinking of a mix of versioning tools used for sandbox projects, boost trunk, etc., causing an unnecessarily steep learning curve. But if individual projects are to be hosted separately anyhow, that's much less of a concern (though it would still be useful to have clear and up-to-date guidelines for directory layout, build system, etc., to make it easier to merge to trunk should we ever get this far).
Is setting up Jamroot / Jamfiles still the recommended way of getting started? Cheers, Darren
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Darren Garvey Sent: Tuesday, May 28, 2013 3:47 PM To: boost@lists.boost.org Cc: Dave Abrahams; Stjepan Rajko Subject: [boost] [gsoc] Getting started with a repository (Was: Re: Live read-only GIT mirrors of Boost trunk SVN)
Following on from an earlier discussion...
On 4 May 2013 20:00, Stefan Seefeld <stefan@seefeld.name> wrote:
On 05/04/2013 01:25 PM, Dave Abrahams wrote:
on Sat May 04 2013, Stefan Seefeld <stefan-AT-seefeld.name> wrote:
it would be great if the sandbox could be converted quickly, so GSoC students can use it ? We don't expect anyone to commit to https://github.com/boostorg/sandbox once the transition is complete. In fact, it would be good to stop now. Instead, people should use individual Git repositories.
OK, that makes sense. So sanbox projects become entirely independent with the only dependency being some upstream boost version (which may correspond to either a release or a development version).
So, students can assume that users have boost installed on their machine in a standard location, and can set up a separate git repository for their project. Great.
I remember there used to be a template in the sandbox for getting started; all I see right now is
this:
http://svn.boost.org/svn/boost/sandbox/template_under_construction/
It looks like it's the right kind of thing, but is this still under_construction (cc'ing Stjepan)?
It seems to
produce a basic set of directories, Jamfiles, etc. when following these steps:
svn co http://svn.boost.org/svn/boost/sandbox/template_under_construction/ cd template_under_construction python file_template.py sandbox # Answer some question prompts
It would be great if they didn't need to learn a thousand tools before
being able to focus on the project itself, and so having a well-defined and -documented process to set things up and get started would be very helpful. I don't know what you mean here, sorry.
Never mind. I was thinking of a mix of versioning tools used for sandbox projects, boost trunk, etc., causing an unnecessarily steep learning curve. But if individual projects are to be hosted separately anyhow, that's much less of a concern (though it would still be useful to have clear and up-to-date guidelines for directory layout, build system, etc., to make it easier to merge to trunk should we ever get this far).
Is setting up Jamroot / Jamfiles still the recommended way of getting started?
Probably but ... I think the GIT team should make a decision NOW about whether GSOC students should use GIT or not. I think I'm against this, on the grounds that there is a lot to go wrong, and much critical students Google-time, especially with those who may be even ranker amateurs than me ;-) Unless there is a firm commitment from the GIT team to support students using GIT, then I think they should stick to boost-sandbox and do things "the old way". Views from the GIT team? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
I vote for Paul's argument. It's better if there is a new repo for the GSOCs where they can work. And, the important changes are made to the main repo. On Tue, May 28, 2013 at 8:43 PM, Paul A. Bristow <pbristow@hetp.u-net.com>wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Darren Garvey Sent: Tuesday, May 28, 2013 3:47 PM To: boost@lists.boost.org Cc: Dave Abrahams; Stjepan Rajko Subject: [boost] [gsoc] Getting started with a repository (Was: Re: Live read-only GIT mirrors of Boost trunk SVN)
Following on from an earlier discussion...
On 4 May 2013 20:00, Stefan Seefeld <stefan@seefeld.name> wrote:
On 05/04/2013 01:25 PM, Dave Abrahams wrote:
on Sat May 04 2013, Stefan Seefeld <stefan-AT-seefeld.name> wrote:
it would be great if the sandbox could be converted quickly, so GSoC students can use it ? We don't expect anyone to commit to https://github.com/boostorg/sandbox once the transition is complete. In fact, it would be good to stop now. Instead, people should use individual Git repositories.
OK, that makes sense. So sanbox projects become entirely independent with the only dependency being some upstream boost version (which may correspond to either a release or a development version).
So, students can assume that users have boost installed on their machine in a standard location, and can set up a separate git repository for their project. Great.
I remember there used to be a template in the sandbox for getting started; all I see right now is this:
http://svn.boost.org/svn/boost/sandbox/template_under_construction/
It looks like it's the right kind of thing, but is this still under_construction (cc'ing Stjepan)? It seems to produce a basic set of directories, Jamfiles, etc. when following these steps:
svn co http://svn.boost.org/svn/boost/sandbox/template_under_construction/ cd template_under_construction python file_template.py sandbox # Answer some question prompts
It would be great if they didn't need to learn a thousand tools before
being able to focus on the project itself, and so having a well-defined and -documented process to set things up and get started would be very helpful. I don't know what you mean here, sorry.
Never mind. I was thinking of a mix of versioning tools used for sandbox projects, boost trunk, etc., causing an unnecessarily steep learning curve. But if individual projects are to be hosted separately anyhow, that's much less of a concern (though it would still be useful to have clear and up-to-date guidelines for directory layout, build system, etc., to make it easier to merge to trunk should we ever get this far).
Is setting up Jamroot / Jamfiles still the recommended way of getting started?
Probably but ...
I think the GIT team should make a decision NOW about whether GSOC students should use GIT or not.
I think I'm against this, on the grounds that there is a lot to go wrong, and much critical students Google-time, especially with those who may be even ranker amateurs than me ;-)
Unless there is a firm commitment from the GIT team to support students using GIT, then I think they should stick to boost-sandbox and do things "the old way".
Views from the GIT team?
Paul
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ---------------- Atluri Aditya Avinash, India.
I think the GIT team should make a decision NOW about whether GSOC students should use GIT or not.
I think I'm against this, on the grounds that there is a lot to go wrong, and much critical students Google-time, especially with those who may be even ranker amateurs than me ;-)
+1
Unless there is a firm commitment from the GIT team to support students using GIT, then I think they should stick to boost-sandbox and do things "the old way".
Views from the GIT team? Paul
...Or their mentors! I'm mentoring a project and I'm a total, absolute git-beginner (used it, like, only sporadically for one small repo). Is there any way to send git newbies like me and my student to the sandbox, at least one more year? Sincerely, Chris.
On 28 May 2013 17:56, Christopher Kormanyos <e_float@yahoo.com> wrote:
I think the GIT team should make a decision NOW about whether GSOC students should use GIT or not.
I think I'm against this, on the grounds that there is a lot to go wrong, and much critical students Google-time, especially with those who may be even ranker amateurs than me ;-)
+1
I guess ultimately it's easy to move from a standalone git repo back to the svn sandbox. The advantage of git is having a nice public place like github available to make collaboration easy.
Unless there is a firm commitment from the GIT team to support students using GIT, then I think they should stick to boost-sandbox and do things "the old way".
Views from the GIT team? Paul
...Or their mentors!
I'm mentoring a project and I'm a total, absolute git-beginner (used it, like, only sporadically for one small repo).
You'd be surprised how quickly you pick it up. </aside>
Is there any way to send git newbies like me and my student to the sandbox, at least one more year?
Personally, I think whatever is easiest for the student in question is best. Getting the basics set up and out of the way asap is the goal and there's already a way to do that with svn (as I mentioned in the first post). Attached to this post is a really basic script that uses Stjepan's template_under_construction to give you a bare-bones git repo, if that's what you prefer. Cheers, Darren
My € 0.02 from the Git crew: I can only underline what Darren wrote:
Personally, I think whatever is easiest for the student in question is best.
Let them decide. If the students prefer the Boost sandbox over GitHub, that's fine. However, I highly doubt it. At least the students I know are more comfortable with Git than with SVN these days. And GitHub has other benefits. Mentors actually don't need any knowledge about Git at all. You see the code on the website with syntax highlighting. You can comment on commits. You can add comments to individual lines in the source code. If you want to try out the project, you can download it as tarball or zip archive. Students will need to know how to commit changes and syncronize with a remote repository. You learn that here: http://try.github.io Ready? Shall we use https://github.com/BoostGSOC as a common place for all GSOC repositories?
So, students can assume that users have boost installed on their machine in a standard location, and can set up a separate git repository for their project. Great.
Right! Please spare the students with complicated setup. Let them concentrate on code. Also, please let them choose their favorite build system. cheers, Daniel
On 29 May 2013 10:48, Daniel Pfeifer <daniel@pfeifer-mail.de> wrote:
Let them decide.
Since most of the projects are based on extending existing libraries, they *might* be constrained by the need to integrate with the library. I'm sure that learning how to work with an established project is an important part of GSOC.
My € 0.02 from the Git crew:
I can only underline what Darren wrote:
Personally, I think whatever is easiest for the student in question is best.
Let them decide. If the students prefer the Boost sandbox over GitHub, that's fine. However, I highly doubt it. At least the students I know are more comfortable with Git than with SVN these days. And GitHub has other benefits.
Mentors actually don't need any knowledge about Git at all. You see the code on the website with syntax highlighting. You can comment on commits. You can add comments to individual lines in the source code. If you want to try out the project, you can download it as tarball or zip archive.
Students will need to know how to commit changes and syncronize with a remote repository. You learn that here: http://try.github.io
Ready? Shall we use https://github.com/BoostGSOC as a common place for all GSOC repositories?
OK, I guess I could go for that for my GSoC project, even though I relish resisting change.:-)
So, students can assume that users have boost installed on their machine in a standard location, and can set up a separate git repository for their project. Great.
Right! Please spare the students with complicated setup. Let them concentrate on code.
<snip> What is your advice for a project (say mine) where a student might contribute, say, 10 files over the course of the project to Boost.Math, whereby math consists of hundreds of files? The GSoC files under construction are to be deeply nested within Boost.Math and can not be used without much of Boost. How should the student merge in order to check operation with trunk? With a merge tool? Which one? Do we really have to copy files back and forth? or is there a better way? I am so rank idiot here! Does each student need to make a carbon copy of trunk in their GSoC repo? I'm a little lost here and request guidance. Sincerely, Chris.
On 29 May 2013 11:47, Christopher Kormanyos <e_float@yahoo.com> wrote:
What is your advice for a project (say mine) where a student might contribute, say, 10 files over the course of the project to Boost.Math, whereby math consists of hundreds of files? The GSoC files under construction are to be deeply nested within Boost.Math and can not be used without much of Boost.
How should the student merge in order to check operation with trunk? With a merge tool? Which one? Do we really have to copy files back and forth? or is there a better way?
I am so rank idiot here! Does each student need to make a carbon copy of trunk in their GSoC repo?
I'm a little lost here and request guidance.
Daniel knows better about whether this is a sensible option, but if you chose to go down the git route you could use the modularised boost repo: 1. Set up a github account 2. Fork https://github.com/boostorg/math into your own repo 3. Hack and review changes on the fork 4. Changes that reach a production-ready state could be sent as pull-requests to the main repo. * * This bit might not work yet. Even if it doesn't, patches could be created from the git repo and applied manually to the boost svn repo by a Boost.Math author. Cheers, Darren
2013/5/29 Darren Garvey <darren.garvey@gmail.com>
On 29 May 2013 11:47, Christopher Kormanyos <e_float@yahoo.com> wrote:
What is your advice for a project (say mine) where a student might contribute, say, 10 files over the course of the project to Boost.Math, whereby math consists of hundreds of files? The GSoC files under construction are to be deeply nested within Boost.Math and can not be used without much of Boost.
How should the student merge in order to check operation with trunk? With a merge tool? Which one? Do we really have to copy files back and forth? or is there a better way?
I am so rank idiot here! Does each student need to make a carbon copy of trunk in their GSoC repo?
I'm a little lost here and request guidance.
Daniel knows better about whether this is a sensible option, but if you chose to go down the git route you could use the modularised boost repo:
1. Set up a github account 2. Fork https://github.com/boostorg/math into your own repo
That would be great right? Unfortunately this is not an option. The modularization is still work in progress. Each time we make changes to the the modularization tool, it will force-push to this repository. It's history will be completely rewritten and will not be common anymore with your clone. As a consequence, you will not be able to merge the changes. Therefore: DON'T clone or fork the repositories at https://github.com/boostorg/ <https://github.com/boostorg/math> 3. Hack and review changes on the fork
4. Changes that reach a production-ready state could be sent as pull-requests to the main repo. *
* This bit might not work yet. Even if it doesn't, patches could be created from the git repo and applied manually to the boost svn repo by a Boost.Math author.
Cheers,
Darren
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ready? Shall we use https://github.com/BoostGSOC as a common place for all GSOC repositories?
Actually, I'm kind of warming up to the idea. Getting all 7 GSoC projects in 7 repos at BoostGSOC would certainly leave a good impression and signalize that we are coordinated in GSoC. (And I believe we are).
So, students can assume that users have boost installed on their machine in a standard location, and can set up a separate git repository for their project. Great.
Right! Please spare the students with complicated setup.
Oh, I think I'm starting to get it. Do you mean that students make a git repo containing the new subset of Boost they are writing for GSoC. And they are to equip this repo with the subset of Boost directories mirrored in git directory structure. Any mentor wishing to build this can include their local boost installation or trunk *plus* the repo of the student. Include both directories via compiler options, and building/testing is easy. Is this kind of what you are talking about? Sincerely, Chris.
2013/5/29 Christopher Kormanyos <e_float@yahoo.com>
Ready? Shall we use https://github.com/BoostGSOC as a common place for all GSOC repositories?
Actually, I'm kind of warming up to the idea. Getting all 7 GSoC projects in 7 repos at BoostGSOC would certainly leave a good impression and signalize that we are coordinated in GSoC. (And I believe we are).
So, students can assume that users have boost installed on their machine in a standard location, and can set up a separate git repository for their project. Great.
Right! Please spare the students with complicated setup.
Oh, I think I'm starting to get it.
Do you mean that students make a git repo containing the new subset of Boost they are writing for GSoC.
Yes. However, I did not consider your use case with Boost.Math. This may be more complicated. And they are to equip this repo with the subset of
Boost directories mirrored in git directory structure.
Not exactly. I really meant "students can assume that users have boost installed on their machine in a standard location". So you don't need to put any Boost files into your repository but your own ones.
Any mentor wishing to build this can include their local boost installation or trunk *plus* the repo of the student. Include both directories via compiler options, and building/testing is easy.
Is this kind of what you are talking about?
Yes, that was my idea.
<snip>
Any mentor wishing to build this can include their local boost installation or trunk *plus* the repo of the student. Include both directories via compiler options, and building/testing is easy.
Is this kind of what you are talking about?
Yes, that was my idea.
Well that sounds straight forward enough. I can go for that. Thanks for the patient clarifications. Sincerely, Chris.
participants (6)
-
Aditya Avinash -
Christopher Kormanyos -
Daniel James -
Daniel Pfeifer -
Darren Garvey -
Paul A. Bristow