Hi, I'm not sure I'm allowed to write to this list for GSoC questions, but it looks like most of the people interested in this application can be found only here, so I took a chance.
I'm a student from Romania, looking to hack some Ruby code during this summer and I found Fedora as one of the not so many organizations offering this opportunity.
I read the whole thread, and I found suggestions and conditions you need from a student, pleasant for myself.
I know Ruby (among other programming languages) and I know sysadmining. Previously I had 2 successful GSoC editions with WordPress Foundation, and my first year project latest commit dates March 14th, this year.
The only problem I can for-see, is that I had and still maintain deep involvement in Ubuntu community (I'm the infrastructure admin for ubuntu-ro). I don't know if this is an issue or not, but I really hope this wont affect in any way our relationship (here in Romania, we do Barcamps every year with fedora-ro, with beer, hiking and lots of pics, thx to @nicubunu http://camp.softwareliber.ro/2011/poze ). :)
If all this stuff sounds interesting, I would be happy to present a draft on how we could solve FedoraHosted transition to Gitlab, and ensure its well maintained from now on.
Lately I started to hang on #fedora-summer-coding|#jbosstesting@freenode, but I'm not sure whom I should query. I can't see Dan either online.
I also have a Github account: https://github.com/stas and a resume: http://stas.github.com/resume.html
Thanks in advance for reading this, and I'm looking forward for your reply.
P.S.: I will also be ok if you would like to find a fedora guy for this project, if so, just let me know, I won't mind. Seriously!
On Mon, 19 Mar 2012 23:42:59 +0200 Stas Sușcov stas@nerd.ro wrote:
Hi, I'm not sure I'm allowed to write to this list for GSoC questions, but it looks like most of the people interested in this application can be found only here, so I took a chance.
Sure. The list is open to all. ;)
I'm a student from Romania, looking to hack some Ruby code during this summer and I found Fedora as one of the not so many organizations offering this opportunity.
I read the whole thread, and I found suggestions and conditions you need from a student, pleasant for myself.
I know Ruby (among other programming languages) and I know sysadmining. Previously I had 2 successful GSoC editions with WordPress Foundation, and my first year project latest commit dates March 14th, this year.
The only problem I can for-see, is that I had and still maintain deep involvement in Ubuntu community (I'm the infrastructure admin for ubuntu-ro). I don't know if this is an issue or not, but I really hope this wont affect in any way our relationship (here in Romania, we do Barcamps every year with fedora-ro, with beer, hiking and lots of pics, thx to @nicubunu http://camp.softwareliber.ro/2011/poze ). :)
I see no problem with being in a number of communities. As long as you have time/energy to do so, more power to you. ;)
If all this stuff sounds interesting, I would be happy to present a draft on how we could solve FedoraHosted transition to Gitlab, and ensure its well maintained from now on.
Lately I started to hang on #fedora-summer-coding|#jbosstesting@freenode, but I'm not sure whom I should query. I can't see Dan either online.
I also have a Github account: https://github.com/stas and a resume: http://stas.github.com/resume.html
Thanks in advance for reading this, and I'm looking forward for your reply.
Well, the big hurdles with this project were mentioned in the previous thread. To my mind the first big problem is getting mod_passenger packaged, and thats something that you may not have much control over. (It will be done when it's done).
Next would be making sure that there's a group of people who know how to manage/maintain/operate things so that after the summer is over there's not a abandonded proof of concept no one can use. ;)
kevin
În data de Tue, 20 Mar 2012 16:32:15 +0200, Kevin Fenzi kevin@scrye.com a scris:
On Mon, 19 Mar 2012 23:42:59 +0200 Stas Sușcov stas@nerd.ro wrote:
If all this stuff sounds interesting, I would be happy to present a draft on how we could solve FedoraHosted transition to Gitlab, and ensure its well maintained from now on.
Lately I started to hang on #fedora-summer-coding|#jbosstesting@freenode, but I'm not sure whom I should query. I can't see Dan either online.
I also have a Github account: https://github.com/stas and a resume: http://stas.github.com/resume.html
Thanks in advance for reading this, and I'm looking forward for your reply.
Well, the big hurdles with this project were mentioned in the previous thread. To my mind the first big problem is getting mod_passenger packaged, and thats something that you may not have much control over. (It will be done when it's done).
Next would be making sure that there's a group of people who know how to manage/maintain/operate things so that after the summer is over there's not a abandonded proof of concept no one can use. ;)
Thanks a lot for openness! :)
Not sure passenger is the problem. Gitlab uses the awesome Resque[1], so you will need something like foreman[2] to run the app with it's workers all together (at least this is the easiest way to do that). I would go with a different stack like unicorn[4] as the webserver and use apache (if you really want to keep it, other-way I would consider nginx) as a reverse proxy.
[1]: https://github.com/gitlabhq/gitlabhq/blob/master/Gemfile#L29 [2]: http://devcenter.heroku.com/articles/procfile#developing_locally_with_forema... [3]: https://github.com/gitlabhq/gitlabhq/blob/master/Procfile.production [4]: https://github.com/blog/517-unicorn
On Tue, 20 Mar 2012 16:39:42 +0200 Stas Sușcov stas@nerd.ro wrote:
Not sure passenger is the problem. Gitlab uses the awesome Resque[1], so you will need something like foreman[2] to run the app with it's workers all together (at least this is the easiest way to do that). I would go with a different stack like unicorn[4] as the webserver and use apache (if you really want to keep it, other-way I would consider nginx) as a reverse proxy.
1. For authentication/authorization I think apache is going to be a requirement
2. Packaging is critical - we will not be installing a thousand gems directly. They will need to be packaged.
one thing I've not understood about gitlabhq as a development project is where is the development portion of it? We're not talking about writing much code, I think. It is mostly about setting up and integrating gitlabhq into the overall fedorahosted infrastructure.
-sv
În data de Tue, 20 Mar 2012 16:47:01 +0200, seth vidal skvidal@fedoraproject.org a scris:
On Tue, 20 Mar 2012 16:39:42 +0200 Stas Sușcov stas@nerd.ro wrote:
Not sure passenger is the problem. Gitlab uses the awesome Resque[1], so you will need something like foreman[2] to run the app with it's workers all together (at least this is the easiest way to do that). I would go with a different stack like unicorn[4] as the webserver and use apache (if you really want to keep it, other-way I would consider nginx) as a reverse proxy.
- For authentication/authorization I think apache is going to be a
requirement
- Packaging is critical - we will not be installing a thousand gems
directly. They will need to be packaged.
one thing I've not understood about gitlabhq as a development project is where is the development portion of it? We're not talking about writing much code, I think. It is mostly about setting up and integrating gitlabhq into the overall fedorahosted infrastructure.
Looks like packaging the Gitlab dependencies might be an issue, mostly because of their number and because that number might change in time.
Should we consider setting up an on-demand buildbot for gems. This way users will be able to submit requests for automatic building of gems?
On Tue, 20 Mar 2012 17:00:06 +0200 Stas Sușcov stas@nerd.ro wrote:
Looks like packaging the Gitlab dependencies might be an issue, mostly because of their number and because that number might change in time.
Yeah, it's going to be a lot of work for sure.
Should we consider setting up an on-demand buildbot for gems. This way users will be able to submit requests for automatic building of gems?
You could setup such a thing, but we are not going to use something like that for packages that we deploy. ;)
kevin
Not only mod passenger, gitlabhq codebase is uses ruby 1.9. features, so we'll need to package ruby 1.9 also. Also we need to test it against existing gitolite rpm
On Tue, Mar 20, 2012 at 8:09 PM, Stas Sușcov stas@nerd.ro wrote:
În data de Tue, 20 Mar 2012 16:32:15 +0200, Kevin Fenzi kevin@scrye.com a scris:
On Mon, 19 Mar 2012 23:42:59 +0200
Stas Sușcov stas@nerd.ro wrote:
If all this stuff sounds interesting, I would be happy to present a
draft on how we could solve FedoraHosted transition to Gitlab, and ensure its well maintained from now on.
Lately I started to hang on #fedora-summer-coding|#**jbosstesting@freenode, but I'm not sure whom I should query. I can't see Dan either online.
I also have a Github account: https://github.com/stas and a resume: http://stas.github.com/resume.**htmlhttp://stas.github.com/resume.html
Thanks in advance for reading this, and I'm looking forward for your reply.
Well, the big hurdles with this project were mentioned in the previous thread. To my mind the first big problem is getting mod_passenger packaged, and thats something that you may not have much control over. (It will be done when it's done).
Next would be making sure that there's a group of people who know how to manage/maintain/operate things so that after the summer is over there's not a abandonded proof of concept no one can use. ;)
Thanks a lot for openness! :)
Not sure passenger is the problem. Gitlab uses the awesome Resque[1], so you will need something like foreman[2] to run the app with it's workers all together (at least this is the easiest way to do that). I would go with a different stack like unicorn[4] as the webserver and use apache (if you really want to keep it, other-way I would consider nginx) as a reverse proxy.
locally_with_foremanhttp://devcenter.heroku.com/articles/procfile#developing_locally_with_foreman [3]: https://github.com/gitlabhq/**gitlabhq/blob/master/Procfile.** productionhttps://github.com/gitlabhq/gitlabhq/blob/master/Procfile.production [4]: https://github.com/blog/517-**unicornhttps://github.com/blog/517-unicorn
______________________________**_________________ infrastructure mailing list infrastructure@lists.**fedoraproject.orginfrastructure@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/**infrastructurehttps://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Tue, 20 Mar 2012 20:18:32 +0530 ranjib dey dey.ranjib@gmail.com wrote:
Not only mod passenger, gitlabhq codebase is uses ruby 1.9. features, so we'll need to package ruby 1.9 also. Also we need to test it against existing gitolite rpm
That would require a parallel install-able ruby in epel. (see the python26 in epel5 for precedence)
So, it's possible, but its going to be a lot of work. ;)
kevin
yes indeed, rubio from frameos has already done it (ruby19) and the lot of us (from chef, and RoR community atleast) have tested it out. Any chance we can reuse those specs in?
On Tue, Mar 20, 2012 at 8:24 PM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 20 Mar 2012 20:18:32 +0530 ranjib dey dey.ranjib@gmail.com wrote:
Not only mod passenger, gitlabhq codebase is uses ruby 1.9. features, so we'll need to package ruby 1.9 also. Also we need to test it against existing gitolite rpm
That would require a parallel install-able ruby in epel. (see the python26 in epel5 for precedence)
So, it's possible, but its going to be a lot of work. ;)
kevin
On Tue, 20 Mar 2012 20:26:29 +0530 ranjib dey dey.ranjib@gmail.com wrote:
yes indeed, rubio from frameos has already done it (ruby19) and the lot of us (from chef, and RoR community atleast) have tested it out. Any chance we can reuse those specs in?
As long as they pass Fedora guidelines, are free, and pass review, sure. ;)
kevin
Dne 20.3.2012 15:58, Kevin Fenzi napsal(a):
On Tue, 20 Mar 2012 20:26:29 +0530 ranjib deydey.ranjib@gmail.com wrote:
yes indeed, rubio from frameos has already done it (ruby19) and the lot of us (from chef, and RoR community atleast) have tested it out. Any chance we can reuse those specs in?
As long as they pass Fedora guidelines, are free, and pass review, sure. ;)
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
F17 and above has already Ruby 1.9.3
Vit
On Tue, 03 Apr 2012 07:23:51 +0200 Vít Ondruch vondruch@redhat.com wrote:
Dne 20.3.2012 15:58, Kevin Fenzi napsal(a):
On Tue, 20 Mar 2012 20:26:29 +0530 ranjib deydey.ranjib@gmail.com wrote:
yes indeed, rubio from frameos has already done it (ruby19) and the lot of us (from chef, and RoR community atleast) have tested it out. Any chance we can reuse those specs in?
As long as they pass Fedora guidelines, are free, and pass review, sure. ;)
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
F17 and above has already Ruby 1.9.3
Sure, but we don't typically run Fedora instances in Fedora Infrastructure. The update churn and short lifespan make it not very viable in many cases.
Also, puppet is broken in f17/f18 currently, making it extra difficult to manage/deploy.
kevin
On Tue, 20 Mar 2012 16:39:42 +0200 Stas Sușcov stas@nerd.ro wrote:
Thanks a lot for openness! :)
No problem. We aim to be open. ;)
Not sure passenger is the problem. Gitlab uses the awesome Resque[1], so you will need something like foreman[2] to run the app with it's workers all together (at least this is the easiest way to do that).
I would go with a different stack like unicorn[4] as the webserver and use apache (if you really want to keep it, other-way I would consider nginx) as a reverse proxy.
Well, the problem with all these things is that they are not packaged in Fedora/EPEL.
Our deployment and management of systems depends on having rpm packages available for Fedora/EPEL. This lets us be sure of the following:
* The package is free by Fedora's definitions of Free.
* The package doesn't bundle other libs that could cause a variety of issues.
* The package has at least one maintainer and we can file bugs against it in bugzilla.redhat.com.
* The packages are signed and built in a sane build env.
In any case, we don't want to deploy things that are not packaged, so the big hurdle here is getting the stack of things you need to deploy this packaged. ;)
kevin
Just as a side-note, Puppet Labs for GSOC has a project for a puppet module for complete deployment (all services) for Gitlab as well.
http://projects.puppetlabs.com/projects/puppet/wiki/GSOC12
Any progress on packaging and deployment would be a neat thing to share.
stahnma
On Tue, Mar 20, 2012 at 7:32 AM, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 19 Mar 2012 23:42:59 +0200 Stas Sușcov stas@nerd.ro wrote:
Hi, I'm not sure I'm allowed to write to this list for GSoC questions, but it looks like most of the people interested in this application can be found only here, so I took a chance.
Sure. The list is open to all. ;)
I'm a student from Romania, looking to hack some Ruby code during this summer and I found Fedora as one of the not so many organizations offering this opportunity.
I read the whole thread, and I found suggestions and conditions you need from a student, pleasant for myself.
I know Ruby (among other programming languages) and I know sysadmining. Previously I had 2 successful GSoC editions with WordPress Foundation, and my first year project latest commit dates March 14th, this year.
The only problem I can for-see, is that I had and still maintain deep involvement in Ubuntu community (I'm the infrastructure admin for ubuntu-ro). I don't know if this is an issue or not, but I really hope this wont affect in any way our relationship (here in Romania, we do Barcamps every year with fedora-ro, with beer, hiking and lots of pics, thx to @nicubunu http://camp.softwareliber.ro/2011/poze ). :)
I see no problem with being in a number of communities. As long as you have time/energy to do so, more power to you. ;)
If all this stuff sounds interesting, I would be happy to present a draft on how we could solve FedoraHosted transition to Gitlab, and ensure its well maintained from now on.
Lately I started to hang on #fedora-summer-coding|#jbosstesting@freenode, but I'm not sure whom I should query. I can't see Dan either online.
I also have a Github account: https://github.com/stas and a resume: http://stas.github.com/resume.html
Thanks in advance for reading this, and I'm looking forward for your reply.
Well, the big hurdles with this project were mentioned in the previous thread. To my mind the first big problem is getting mod_passenger packaged, and thats something that you may not have much control over. (It will be done when it's done).
Next would be making sure that there's a group of people who know how to manage/maintain/operate things so that after the summer is over there's not a abandonded proof of concept no one can use. ;)
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Stas,
I didn't mean to leave you hanging (I've been really backlogged atm). That aside...I am *thrilled* that you've expressed interest in the gitlab adoption/migration project. With the success of github in mind as a model, I see tremendous potential for the impact this can have on the Fedora community and every community that extends from it. The transparency and insight that gitlab offers into the source code (just as github does) cannot be underestimated. It makes open source...eye opening.
I recognize there are some big hurdles in this project, and there's no question it will be a touch challenge. But there are two guiding lights here:
- There are other groups that need this packaging problem solved (e.g., mod_passanger), so you are not alone (the open source openshift stack needs this as well, and badly, so the ball will be rolling well before the summer begins) - This will be one of the most visible outcomes, if successful, across all of GSoC. People will come out of the hedges to support it, everything in my gut leads me to believe that.
I don't want be overly optimistic, but hopefully that expresses some of the reasoning that compelled me to propose the project.
As I mentioned in the other thread, I'll be around, but not likely a mentor. Anyone else here would be a better fit, plus I'm already over-committed to projects atm. However, what I can do is assist where I can to get in touch with people that are interested in assisting with the project, will become part of the long-term support team or can solve issues beyond your control. Even the gitlab team has expressed interest in doing whatever they can to support the adoption, so you won't be alone.
Ask questions, be bold, acknowledge the challenges and don't be afraid to share your own vision for the project. I'll finish with advice my my grandfather told me many times, "where there's a will, there's a way".
Cheers,
-Dan
On Mon, Mar 19, 2012 at 17:42, Stas Sușcov stas@nerd.ro wrote:
Hi, I'm not sure I'm allowed to write to this list for GSoC questions, but it looks like most of the people interested in this application can be found only here, so I took a chance.
I'm a student from Romania, looking to hack some Ruby code during this summer and I found Fedora as one of the not so many organizations offering this opportunity.
I read the whole thread, and I found suggestions and conditions you need from a student, pleasant for myself.
I know Ruby (among other programming languages) and I know sysadmining. Previously I had 2 successful GSoC editions with WordPress Foundation, and my first year project latest commit dates March 14th, this year.
The only problem I can for-see, is that I had and still maintain deep involvement in Ubuntu community (I'm the infrastructure admin for ubuntu-ro). I don't know if this is an issue or not, but I really hope this wont affect in any way our relationship (here in Romania, we do Barcamps every year with fedora-ro, with beer, hiking and lots of pics, thx to @nicubunu http://camp.softwareliber.ro/**2011/pozehttp://camp.softwareliber.ro/2011/poze). :)
If all this stuff sounds interesting, I would be happy to present a draft on how we could solve FedoraHosted transition to Gitlab, and ensure its well maintained from now on.
Lately I started to hang on #fedora-summer-coding|#**jbosstesting@freenode, but I'm not sure whom I should query. I can't see Dan either online.
I also have a Github account: https://github.com/stas and a resume: http://stas.github.com/resume.**htmlhttp://stas.github.com/resume.html
Thanks in advance for reading this, and I'm looking forward for your reply.
P.S.: I will also be ok if you would like to find a fedora guy for this project, if so, just let me know, I won't mind. Seriously! ______________________________**_________________ infrastructure mailing list infrastructure@lists.**fedoraproject.orginfrastructure@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/**infrastructurehttps://admin.fedoraproject.org/mailman/listinfo/infrastructure
În data de Tue, 20 Mar 2012 19:47:46 +0200, Dan Allen dan.j.allen@gmail.com a scris:
Stas,
I didn't mean to leave you hanging (I've been really backlogged atm).
No worries, was just hoping an irc chat would save us from a bunch of emails.
That aside...I am *thrilled* that you've expressed interest in the gitlab adoption/migration project. With the success of github in mind as a model, I see tremendous potential for the impact this can have on the Fedora community and every community that extends from it. The transparency and insight that gitlab offers into the source code (just as github does) cannot be underestimated. It makes open source...eye opening.
Can't agree more.
I recognize there are some big hurdles in this project, and there's no question it will be a touch challenge. But there are two guiding lights here:
- There are other groups that need this packaging problem solved (e.g.,
mod_passanger), so you are not alone (the open source openshift stack needs this as well, and badly, so the ball will be rolling well before the summer begins)
- This will be one of the most visible outcomes, if successful, across
all of GSoC. People will come out of the hedges to support it, everything in my gut leads me to believe that.
I don't want be overly optimistic, but hopefully that expresses some of the reasoning that compelled me to propose the project.
As I mentioned in the other thread, I'll be around, but not likely a mentor. Anyone else here would be a better fit, plus I'm already over-committed to projects atm. However, what I can do is assist where I can to get in touch with people that are interested in assisting with the project, will become part of the long-term support team or can solve issues beyond your control. Even the gitlab team has expressed interest in doing whatever they can to support the adoption, so you won't be alone.
Ask questions, be bold, acknowledge the challenges and don't be afraid to share your own vision for the project. I'll finish with advice my my grandfather told me many times, "where there's a will, there's a way".
Thanks a lot for encouragement. So far looks like a big problem is packaging, and although packaging is not the real scope of this project, it sounds fair for me to consider helping packagers bring the tools the project will need the best way. I'm really glad I could raise the questions that were discussed recently, since this will help a lot to draft a good application.
Regarding mentorship, I wouldn't make it a big problem. I believe technical assistance won't be needed, if we can manage the communication with the infrastructure team (probably through this list), that should be pretty much enough for me to finish the project successfully (still, you will probably have to respond to Google's evaluation requests or code reviews).
I'll stay in touch through this list if there are any other questions that need to be addressed.
infrastructure@lists.fedoraproject.org
-
Dan Allen -
Kevin Fenzi -
Michael Stahnke -
Ranjib Dey -
Seth Vidal -
Stas Sușcov -
Vít Ondruch