Greetings from a newly registered member!
I've seen the 'GSoC @ Infra' thread but I didn't want to hijack it nor do I know how to reply to a thread through mailman...
I will be applying for GSoC this summer and GitLab is my first priority as I have been using it since version 2 and I want to contribute in any way I can. I have been talking with Vit Ondruch about the packaging procedure and I just sent a mail [0] to the ruby-sig list too, regarding this.
I have also read last year's discussion [1] and it was made clear by Dan Allen [2] that besides the whole implementation thing, it is as important to find some people that will maintain the project longterm. And I am willing to do this. I don't know if it is possible for more than one person to work on a project during GSoC, but another fellow is interested in this as well [3]. So, now we are two :p
This should be very interesting and I am looking forward to hearing from the infra team :)
Regards,
Axilleas
[0] https://lists.fedoraproject.org/pipermail/ruby-sig/2013-March/001270.html [1] https://lists.fedoraproject.org/pipermail/infrastructure/2012-March/011466.h... [2] https://groups.google.com/forum/?fromgroups=#!topic/gitlabhq/SQMDi-yyXmU [3] https://lists.fedoraproject.org/pipermail/summer-coding/2013-March/000286.ht...
On Sat, 02 Mar 2013 04:44:39 +0200 Axilleas Pipinellis axilleas@archlinux.gr wrote:
Greetings from a newly registered member!
I've seen the 'GSoC @ Infra' thread but I didn't want to hijack it nor do I know how to reply to a thread through mailman...
I will be applying for GSoC this summer and GitLab is my first priority as I have been using it since version 2 and I want to contribute in any way I can. I have been talking with Vit Ondruch about the packaging procedure and I just sent a mail [0] to the ruby-sig list too, regarding this.
Excellent. ;)
I have also read last year's discussion [1] and it was made clear by Dan Allen [2] that besides the whole implementation thing, it is as important to find some people that will maintain the project longterm. And I am willing to do this. I don't know if it is possible for more than one person to work on a project during GSoC, but another fellow is interested in this as well [3]. So, now we are two :p
This should be very interesting and I am looking forward to hearing from the infra team :)
Sure. We have talked about this as well... I think the important thing to focus on right now is the packaging. Until it's packaged and up to Fedora guidelines, we aren't likely to look at deploying it. :)
Once the packaging hurdle is overcome, yeah, we would want a team to help manage it and deploy it and keep it running.
Do see: http://infrastructure.fedoraproject.org/infra/docs/requestforresources.txt and https://fedoraproject.org/wiki/Request_For_Resources
For our process on adding a new stupported application. It's kind of lengthy, but we want to make sure things are supportable and maintainable.
Good luck and keep us posted on the packaging process. ;)
kevin
On Sun, Mar 3, 2013 at 10:24 AM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 02 Mar 2013 04:44:39 +0200 Axilleas Pipinellis axilleas@archlinux.gr wrote:
Greetings from a newly registered member!
I've seen the 'GSoC @ Infra' thread but I didn't want to hijack it nor do I know how to reply to a thread through mailman...
I will be applying for GSoC this summer and GitLab is my first priority as I have been using it since version 2 and I want to contribute in any way I can. I have been talking with Vit Ondruch about the packaging procedure and I just sent a mail [0] to the ruby-sig list too, regarding this.
Excellent. ;)
Very excellent!
I have also read last year's discussion [1] and it was made clear by Dan Allen [2] that besides the whole implementation thing, it is as important to find some people that will maintain the project longterm. And I am willing to do this. I don't know if it is possible for more than one person to work on a project during GSoC, but another fellow is interested in this as well [3]. So, now we are two :p
Great news! Thank you for stepping forward.
One of the key reasons I've been pushing for GitLab is because I see the potential it has for drastically improving the discoverability of the Fedora code base and encourage participation. I've been involved with a lot of projects on GitHub and I'm amazed by how simple it is to submit changes (to both code and documentation). In fact, it's often easier to send a patch with a description of the change than to create an issue...flipping the normal bug submitting process on its head.
GitHub also works because it enables collaboration over coordination. You don't have to ask for permission on GitHub. You just do it. Then you can easily track when they get pulled in or changes are requested. (the same is true of GitLab).
With GitLab, we can bring that experience to the Fedora community. It's a large enough community (esp in terms of repositories), that I'm positive we'd see that collaboration kindle within the Fedora instance.
...so this is a big deal.
-Dan
On 03/12/2013 09:33 AM, Dan Allen wrote:
Great news! Thank you for stepping forward.
One of the key reasons I've been pushing for GitLab is because I see the potential it has for drastically improving the discoverability of the Fedora code base and encourage participation. I've been involved with a lot of projects on GitHub and I'm amazed by how simple it is to submit changes (to both code and documentation). In fact, it's often easier to send a patch with a description of the change than to create an issue...flipping the normal bug submitting process on its head.
GitHub also works because it enables collaboration over coordination. You don't have to ask for permission on GitHub. You just do it. Then you can easily track when they get pulled in or changes are requested. (the same is true of GitLab).
With GitLab, we can bring that experience to the Fedora community. It's a large enough community (esp in terms of repositories), that I'm positive we'd see that collaboration kindle within the Fedora instance.
...so this is a big deal.
-Dan
Hi Dan, thanks for replying!
As Kevin said, let's see how the packaging will go and then we can start working at deploying it. I'll see to make a draft of the process I have in mind in the following week.
The only drawback I see in case GitLab becomes fedorahosted's frontend, is that for someone to see the code in a project, they have to be part of the team. Repositories are kind of private.
On Tue, 12 Mar 2013 01:33:07 -0600 Dan Allen dan.j.allen@gmail.com wrote:
On Sun, Mar 3, 2013 at 10:24 AM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 02 Mar 2013 04:44:39 +0200 Axilleas Pipinellis axilleas@archlinux.gr wrote:
Greetings from a newly registered member!
I've seen the 'GSoC @ Infra' thread but I didn't want to hijack it nor do I know how to reply to a thread through mailman...
I will be applying for GSoC this summer and GitLab is my first priority as I have been using it since version 2 and I want to contribute in any way I can. I have been talking with Vit Ondruch about the packaging procedure and I just sent a mail [0] to the ruby-sig list too, regarding this.
Excellent. ;)
Very excellent!
I have also read last year's discussion [1] and it was made clear by Dan Allen [2] that besides the whole implementation thing, it is as important to find some people that will maintain the project longterm. And I am willing to do this. I don't know if it is possible for more than one person to work on a project during GSoC, but another fellow is interested in this as well [3]. So, now we are two :p
Great news! Thank you for stepping forward.
One of the key reasons I've been pushing for GitLab is because I see the potential it has for drastically improving the discoverability of the Fedora code base and encourage participation. I've been involved with a lot of projects on GitHub and I'm amazed by how simple it is to submit changes (to both code and documentation). In fact, it's often easier to send a patch with a description of the change than to create an issue...flipping the normal bug submitting process on its head.
GitHub also works because it enables collaboration over coordination. You don't have to ask for permission on GitHub. You just do it. Then you can easily track when they get pulled in or changes are requested. (the same is true of GitLab).
With GitLab, we can bring that experience to the Fedora community. It's a large enough community (esp in terms of repositories), that I'm positive we'd see that collaboration kindle within the Fedora instance.
...so this is a big deal.
So - I was following this https://github.com/alexanderte/ansible-playbook-gitlab
and I know ricky elrod is looking into adapting it for us.
if that works and we can deploy new gitlab instances...
my next question is gitlab and openid auth.
-sv
Cross posting from Ruby-sig:
Hello everyone! It's been over a month since I last wrote to this list regarding the GitLab project. I managed to make a blog post of the story so far[0], any feedback welcomed :)
Cheers!
[0] http://axilleas.github.io/en/blog/2013/bringing-gitlab-in-fedora/
On Wed, 10 Apr 2013 21:02:24 +0300 Axilleas Pipinellis axilleas@archlinux.gr wrote:
Cross posting from Ruby-sig:
Hello everyone! It's been over a month since I last wrote to this list regarding the GitLab project. I managed to make a blog post of the story so far[0], any feedback welcomed :)
Just a few things. ;)
1. I think we should stop saying this would replace fedorahosted or change fedorahosted directly. I think very likely we would want this to be a new service all it's own and those people who find the features it offers compelling could switch to using it or start new projects on it. :)
I think some projects would really like the gitlab git handling and issues tracking would be enough for them. Others would prefer the current fedorahosted trac and download space and such. I could see gitlab also being much more used for incubating new projects and then when they are more stable they would also want a fedorahosted space for the other items.
2. we looked more at gitlab recently, and one difficult thing is that it's not so geared for public access. They did add a thing where it will now show a page for public repos with http cloning I think, but aside from that it's very set for all users to sign into it.
https://github.com/gitlabhq/gitlabhq/issues/2549
There are patches around to add a 'guest' user that can look around and see things, but upstream doesn't wish to merge them. See: https://github.com/cjdelisle/gitboria.com/commit/61db393bfd4fc75c5f046f01b01... https://github.com/gitlabhq/gitlabhq/issues/12
Without those patches things are a bit strange for our use case. We want people to be able to view and see everything, even if they don't have an account.
I'm not sure if we would want to carry those patches in our package or come up with some way with upstream to apply them conditionally or something. Someone suggested plugins ability could be used.
Anyhow, just my thoughts... thanks for working on this!
kevin
On Wed, Apr 10, 2013 at 2:15 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 10 Apr 2013 21:02:24 +0300 Axilleas Pipinellis axilleas@archlinux.gr wrote:
Cross posting from Ruby-sig:
Hello everyone! It's been over a month since I last wrote to this list regarding the GitLab project. I managed to make a blog post of the story so far[0], any feedback welcomed :)
I recently deployed GitLab for $DAYJOB and what I found was (at least the big items):
1) As your blog post mentions there are a lot of Ruby gems that GitLab needs that are not packaged.
2) Of the Ruby gems that _are_ packaged, many of them are the wrong version.
3) For some of the Ruby gems that GitLab requires, it requires git snaphots of non-released versions,or versions that have been forked/patched by GitLab developers.
4) I'm not sure GitLab releases tarballs, as the install instructions refer to checking out git branches, even for the stable release branch.
5) There's no ability to fork a project from the web interface, and thus have GitLab track merge requests. There's some upstream work on implementing this feature but all of the patches that I saw had been rejected. Personally, I feel that this is a big show-stopper as it's one of GitHub's best features and why it has become so popular.
6) I have pretty decent systemd service files for GitLab, let me know if you want 'em.
- we looked more at gitlab recently, and one difficult thing is that
it's not so geared for public access.
For my setup, it wasn't as issue as we don't want public access to our instance.
-- Jeff Ollie
Thanks for taking the time to reply :)
Just a few things. ;)
- I think we should stop saying this would replace fedorahosted or
change fedorahosted directly. I think very likely we would want this to be a new service all it's own and those people who find the features it offers compelling could switch to using it or start new projects on it. :)
I think some projects would really like the gitlab git handling and issues tracking would be enough for them. Others would prefer the current fedorahosted trac and download space and such. I could see gitlab also being much more used for incubating new projects and then when they are more stable they would also want a fedorahosted space for the other items.
You are right, indeed. When I think of fedorahosted, I am used to think only the git part. I will correctthis ;)
- we looked more at gitlab recently, and one difficult thing is that
it's not so geared for public access. They did add a thing where it will now show a page for public repos with http cloning I think, but aside from that it's very set for all users to sign into it.
https://github.com/gitlabhq/gitlabhq/issues/2549
There are patches around to add a 'guest' user that can look around and see things, but upstream doesn't wish to merge them. See: https://github.com/cjdelisle/gitboria.com/commit/61db393bfd4fc75c5f046f01b01... https://github.com/gitlabhq/gitlabhq/issues/12
Without those patches things are a bit strange for our use case. We want people to be able to view and see everything, even if they don't have an account.
If you look back at my response [0], that was my concern as well. My hope is that working together with upstream, maybe they will reconsider this and implement such feature. If Fedora decides to make use of it, that will be a big promotion for GitLab, since the app could be easilyinstalledto RHEL or Centos servers.
I'm not sure if we would want to carry those patches in our package or come up with some way with upstream to apply them conditionally or something. Someone suggested plugins ability could be used.
Anyhow, just my thoughts... thanks for working on this!
kevin
We definitely don't want to patchthis ourselves! This would be a stopper I guess. Thanks again for your feedback!
[0] https://lists.fedoraproject.org/pipermail/infrastructure/2013-March/012683.h...
On 04/10/2013 11:21 PM, Jeffrey Ollie wrote:
- Of the Ruby gems that _are_ packaged, many of them are the wrong version.
Yeap! Using http://www.isitfedoraruby.com/stats/gemfile_toolI was able to see this.Some dependencies of Gitlab are also frozen to some previous version. See https://gemnasium.com/gitlabhq/gitlabhq
- For some of the Ruby gems that GitLab requires, it requires git
snaphots of non-released versions,or versions that have been forked/patched by GitLab developers.
That is also trueand could be cumbersome to package.
- I'm not sure GitLab releases tarballs, as the install instructions
refer to checking out git branches, even for the stable release branch.
Luckily, they use tags https://github.com/gitlabhq/gitlabhq/tags
- There's no ability to fork a project from the web interface, and
thus have GitLab track merge requests. There's some upstream work on implementing this feature but all of the patches that I saw had been rejected. Personally, I feel that this is a big show-stopper as it's one of GitHub's best features and why it has become so popular.
I want to believe that at some point this will be implemented. Gitlab has gained a lot of supporters the past year and the project is constantly evolving. Same goes with the repositories' public access that Kevin brought up in his previous mail.
- I have pretty decent systemd service files for GitLab, let me know
if you want 'em.
That would be great, thanks! Email me or contact me via github :)
On 04/10/2013 10:15 PM, Kevin Fenzi wrote:
- we looked more at gitlab recently, and one difficult thing is that
it's not so geared for public access. They did add a thing where it will now show a page for public repos with http cloning I think, but aside from that it's very set for all users to sign into it.
I just wanted to let everyone know that the GitLab team is accepting patches for this long awaited feature :)
http://feedback.gitlab.com/forums/176466-general/suggestions/3159951-allow-p...
infrastructure@lists.fedoraproject.org
-
Axilleas Pipinellis -
Dan Allen -
Jeffrey Ollie -
Kevin Fenzi -
Seth Vidal