Re: GitLab?
On Thu, Mar 5, 2015 at 8:48 PM, Erik Weber terbol...@gmail.com wrote: Github without the web ui or the api wouldn't have the same effect as it has, it would basically be what we currently have.. Well, not totally, since GitHub allows random people creating random projects and random people to host their forks of your project (look at Rails) and publish that fact to the world. Yes, the web UI is paramount to make that popular, but I agree with Mike that ASF should perhaps allow strangers onto our infra, to stay relevant in the next generation, who never experienced Pull Requests by diff -u in Emails By providing a similar service there's nothing that stops git.apache.org (or whatever hostname gitlab would have) to become the new ground where collaboration on Apache projects happen. Agree, subject to allow strangers, which indeed is a massive decision and one that isn't small reversible steps that ASF normally cherish. I've worked on projects residing on gitlab.com without thinking much about it being there rather than on github. But were you invited through a system of meritocracy or did you just created your own fork and hacked away ? I think GitHub has challenged a core value in ASF, discussed for long, and I think ASF should consider the implications and adapt. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
Re: GitLab?
On Thu, Mar 5, 2015 at 9:05 PM, Jim Jagielski j...@jagunet.com wrote: I do feel the need to remind people that there is also Apache Allura, which provides a comprehensive development environment, in fact, more comprehensive than GitHub or GitLab. Plus, last I checked, the PMC was working w/ Infra to ensure that should Allura be installed, there would be people *supporting* the install. Learn something new every day ;-) It would be good to have the developer community in-house, more easily engaged to our specific requests/issues, and perhaps this is better than GitLab for that reason. -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
Re: GitLab?
There is another opensource project that does the same but significantly easier to deploy, manage and upgrade (no dependency hell): http://gogs.io Regards. On Thu, Mar 5, 2015 at 9:05 PM, anto...@gmx.de wrote: Could the ASF not simply run a GitHub Enterprise server ? Sent from my android device. -Original Message- From: David Nalley da...@gnsa.us To: dev@community.apache.org Sent: Thu, 05 Mar 2015 10:15 AM Subject: Re: GitLab? On Wed, Mar 4, 2015 at 10:24 PM, Niclas Hedhman nic...@hedhman.org wrote: Opening a new thread... Git without Github is like sex without a partner, sufficient but not very satisfactory. Github option has been explored in the past, and due to various reasons, it was not possible to achieve. But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Although the Enterprise system cost money, my guess is that GitLab would be happy to waive fees and give us access to EE. Just a thought. [1] https://about.gitlab.com/features/ -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java Infrastructure (at least in the short term) won't deploy Gitlab. The reasoning is this: 1. Most of our demand from projects is for Github, and truthfully, if we could resolve one or two nagging problems, Infra would love to no longer run and administer several hundred git repositories and instead offload that work to Github. 2. There is a lot of infrastructure built up around the existing git infrastructure. Deploying Gitlab or Allura or anything else would require us to figure out authorization, backups, integration with Github, Jira, BZ, svn mirroring, etc; that's a lot of work. IF we were going to tackle such a project it would need to be for all projects, not just a few, and it would be significantly lower on the priority list than a lot of the work we are currently doing. My current thinking (though not yet Foundation policy) is that there is the canonical repository must be managed by Infra, and I suspect that will be in the proposed policy that gets submitted to the board. --David
Re: GitLab?
On Thursday, March 5, 2015, Roman Shaposhnik ro...@shaposhnik.org wrote: On Wed, Mar 4, 2015 at 7:24 PM, Niclas Hedhman nic...@hedhman.org javascript:; wrote: But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Here's the way I look at it: the power of github.com comes not so much from the web UI or even API, but from a network effect. It is where developers congregate. Thus we'd have to have mirrors of our stuff there anyway to enable PR workflow for projects that care about it. And as long as THAT is in place, the need for something like GL is reduced, IMHO. I believe the mirrors are enough for PR workflow, and I personally like the clear borderline. The mirror is read only but you can still submit patches become a committer and get access to the real thing. Building a GITASF extra to what we already have would just add complexity without giving real advantages. That said a lot of projects have their own vm(s) and other can normally get one if requested, so nothing stops a project from providing gitlabs. rgds jan i Thanks, Roman. -- Sent from My iPad, sorry for any misspellings.
Re: GitLab?
Yes, the network effect is important, but is it the only one? Can the network effect happen on ASF systems? Would we want it to? // Niclas On Thu, Mar 5, 2015 at 1:43 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Wed, Mar 4, 2015 at 7:24 PM, Niclas Hedhman nic...@hedhman.org wrote: But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Here's the way I look at it: the power of github.com comes not so much from the web UI or even API, but from a network effect. It is where developers congregate. Thus we'd have to have mirrors of our stuff there anyway to enable PR workflow for projects that care about it. And as long as THAT is in place, the need for something like GL is reduced, IMHO. Thanks, Roman. -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
Re: GitLab?
Looks great Antoine Levy-Lambert - Reply message - From: Rohit Yadav bhais...@apache.org To: dev@community.apache.org Subject: GitLab? Date: Thu, Mar 5, 2015 12:01 PM There is another opensource project that does the same but significantly easier to deploy, manage and upgrade (no dependency hell): http://gogs.io Regards. On Thu, Mar 5, 2015 at 9:05 PM, anto...@gmx.de wrote: Could the ASF not simply run a GitHub Enterprise server ? Sent from my android device. -Original Message- From: David Nalley da...@gnsa.us To: dev@community.apache.org Sent: Thu, 05 Mar 2015 10:15 AM Subject: Re: GitLab? On Wed, Mar 4, 2015 at 10:24 PM, Niclas Hedhman nic...@hedhman.org wrote: Opening a new thread... Git without Github is like sex without a partner, sufficient but not very satisfactory. Github option has been explored in the past, and due to various reasons, it was not possible to achieve. But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Although the Enterprise system cost money, my guess is that GitLab would be happy to waive fees and give us access to EE. Just a thought. [1] https://about.gitlab.com/features/ -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java Infrastructure (at least in the short term) won't deploy Gitlab. The reasoning is this: 1. Most of our demand from projects is for Github, and truthfully, if we could resolve one or two nagging problems, Infra would love to no longer run and administer several hundred git repositories and instead offload that work to Github. 2. There is a lot of infrastructure built up around the existing git infrastructure. Deploying Gitlab or Allura or anything else would require us to figure out authorization, backups, integration with Github, Jira, BZ, svn mirroring, etc; that's a lot of work. IF we were going to tackle such a project it would need to be for all projects, not just a few, and it would be significantly lower on the priority list than a lot of the work we are currently doing. My current thinking (though not yet Foundation policy) is that there is the canonical repository must be managed by Infra, and I suspect that will be in the proposed policy that gets submitted to the board. --David
Re: GitHub Pages
yup ! GH-pages just finds the branch. if its there it displays it. its a totally decoupled publishing tool. ​using gh-pages as a convention could allow automation of th SVN tooling as well, so its really a great, cross platform convention that wont force coupling to github.
Re: GitLab?
Could the ASF not simply run a GitHub Enterprise server ? Sent from my android device. -Original Message- From: David Nalley da...@gnsa.us To: dev@community.apache.org Sent: Thu, 05 Mar 2015 10:15 AM Subject: Re: GitLab? On Wed, Mar 4, 2015 at 10:24 PM, Niclas Hedhman nic...@hedhman.org wrote: Opening a new thread... Git without Github is like sex without a partner, sufficient but not very satisfactory. Github option has been explored in the past, and due to various reasons, it was not possible to achieve. But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Although the Enterprise system cost money, my guess is that GitLab would be happy to waive fees and give us access to EE. Just a thought. [1] https://about.gitlab.com/features/ -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java Infrastructure (at least in the short term) won't deploy Gitlab. The reasoning is this: 1. Most of our demand from projects is for Github, and truthfully, if we could resolve one or two nagging problems, Infra would love to no longer run and administer several hundred git repositories and instead offload that work to Github. 2. There is a lot of infrastructure built up around the existing git infrastructure. Deploying Gitlab or Allura or anything else would require us to figure out authorization, backups, integration with Github, Jira, BZ, svn mirroring, etc; that's a lot of work. IF we were going to tackle such a project it would need to be for all projects, not just a few, and it would be significantly lower on the priority list than a lot of the work we are currently doing. My current thinking (though not yet Foundation policy) is that there is the canonical repository must be managed by Infra, and I suspect that will be in the proposed policy that gets submitted to the board. --David
Re: GitLab?
On Thu, Mar 5, 2015 at 10:35 AM, anto...@gmx.de wrote: Could the ASF not simply run a GitHub Enterprise server ? No, but for varying reasons. We've discussed GH Enterprise server, and one of the licensing points is that you can't expose GH Enterprise Server publicly. Even in our discussions with them, that seems to be a sticking point. Secondly, much of the advantage of Github is the fact its a nexus for developers. The functional differences between GH, Gitlab, Gitorious, Allura, et al, are pretty small. --David
Re: Apache Reporter Service
On 03/03/2015 06:04 PM, Lefty Leverenz wrote: Kudos, Daniel! Great idea. Question 1: How can RMs add release data if they aren't PMC members? (This might be answered by your most recent message.) Sounds like a great opportunity to vote someone onto your PMC. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: GitLab?
On Thu, Mar 5, 2015 at 7:41 AM, David Nalley da...@gnsa.us wrote: On Thu, Mar 5, 2015 at 10:35 AM, anto...@gmx.de wrote: Could the ASF not simply run a GitHub Enterprise server ? No, but for varying reasons. We've discussed GH Enterprise server, and one of the licensing points is that you can't expose GH Enterprise Server publicly. Even in our discussions with them, that seems to be a sticking point. Secondly, much of the advantage of Github is the fact its a nexus for developers. The functional differences between GH, Gitlab, Gitorious, Allura, et al, are pretty small. This should be an FAQ entry in the eventual Infrastructure Policy document. FWIW I fully support Infra's current approach of prioritizing social integration. Marvin Humphrey
Re: Chairs: A small addition to the Marvin email you received yesterday.
Oh, this is pretty great! No more running private-list@ or dev-list@ emails and counting the subscribers! Thank you very much! Cos On Thu, Mar 05, 2015 at 03:31PM, Daniel Gruno wrote: Hi Project chairs, In yesterday's email to you about your upcoming board report, we forgot to mention that we have a new tool that can help you in cobbling together a report, or just view statistics of the PMCs you are on. The new service is located at: https://reporter.apache.org and is PMC members only. Should you choose to make use of the board report template in this system, do remember to add in the important activity bits and any issues that require board activity. Next time Marvin sends you an email, it will include the URL for the reporter system. If you have ANY feedback about this system, don't hesitate to let us know! :) On behalf of the Community Development Project, Daniel.
Re: Chairs: A small addition to the Marvin email you received yesterday.
On Thu, Mar 5, 2015 at 10:39 AM, Konstantin Boudnik c...@apache.org wrote: Oh, this is pretty great! No more running private-list@ or dev-list@ emails and counting the subscribers! Thank you very much! This is an awesome service! Thanks, Roman.
Re: GitLab?
I think it would be interesting to do a trial, perhaps with a couple of willingnew projects. How would you rally projects together to demand it before seeing what it would be like? For me personally, not having to manage VMs with development infrastructure is one additional advantage of moving to Apache - I'm OK to wait for the occasional INFRA requests than having to install patches, monitoring etc. myself. GitLab uses a normal git file-based storage for the repositories, so it should be possible for that file system to be the same one uses by git-wip-us (although git over NFS should raise alarm bells..) I agree with Roman that the social benefit from Github happens at Github - and the pull request integration is a great path into the project for outsiders. ..but that doesn't mean we have to submit totally to Github for normal use of the source code. I believe Gitlab allows sign-in by GitHub id - but I am not so sure about automatic mirroring from Gitlab to GitHub (or pull request integration back again). This could still be achieved the classic way if the repositories remains at git-wip-us. The GitLab issue tracker (which looks very much like GitHub's issue tracker) is an ideal tracker for many projects - not as complex as Jira, and not as arcane as Bugzilla. I have not tested it in detail, but if it has similar email integration as GitHub, then it becomes a smooth integration with the dev@ lists as well. With the GitHub/GitLab style of working you also tend to make several smaller repositories rather than a monolithic $project.git. With a web interface like Gitlab Enterprise, in theory the PMC chairs can be granted karma to click the Create button for their project rather than having to wait for INFRA to run a series of scripts. Now browsing of git repositories is my bugbear.. In my own developer documentation I like to deep-link to the relevant source code rather than just talk about things in the abstract or with Javadoc links - this becomes then also an invitation to explore the code and to contribute. With our own git infrastructure there is not really a usable Browse function - see for example: https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git - Where is the code? Oh, you have to click Tree. - How do I deep-link to code from our website and emails? Links like https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=blob;f=taverna-scufl2-api/src/main/java/org/apache/taverna/scufl2/api/io/WorkflowBundleIO.java;h=03bf3d1ece6674c97747612223f04e3fcd1802fd;hb=de2d370db6f037afa21ca10c3a51f2192aaaddc5 seem unpredictable and are hard to use. - How do I even check out? Do some regular expressions in your head from the current URL. - How do I navigate the code? I have to click manually on README.md files - which are not rendered as Markdown Thus every project has to write a lot of documentation with basic information like how to clone a repository and how to navigate the code base -- or simply send people off to Github (which borders onto product endorsement) and use Apache's git infrastructure as a write-only service. I would consider browsing of the code to be essential for being open for outsiders. Apache insiders will know how to navigate these things, or know when to use Github mirrors - but for anyone incubating into Apache or bumping into an Apache project, being sent into the git-wip-us interface basically looks like Go away. So as Apache is all about the community - we should consider: 1) Github presence is essential 2) Browsing code is essential 3) Apache-controlled infrastructure should be used for day-to-day running of a project On 5 March 2015 at 08:15, Niclas Hedhman nic...@hedhman.org wrote: Yes, the network effect is important, but is it the only one? Can the network effect happen on ASF systems? Would we want it to? // Niclas On Thu, Mar 5, 2015 at 1:43 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Wed, Mar 4, 2015 at 7:24 PM, Niclas Hedhman nic...@hedhman.org wrote: But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Here's the way I look at it: the power of github.com comes not so much from the web UI or even API, but from a network effect. It is where developers congregate. Thus we'd have to have mirrors of our stuff there anyway to enable PR workflow for projects that care about it. And as long as THAT is in place, the need for something like GL is reduced, IMHO. Thanks, Roman. -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy
Re: GitLab?
2015-03-05 11:51 GMT+01:00 Stian Soiland-Reyes st...@apache.org: I think it would be interesting to do a trial, perhaps with a couple of willingnew projects. How would you rally projects together to demand it before seeing what it would be like? For me personally, not having to manage VMs with development infrastructure is one additional advantage of moving to Apache - I'm OK to wait for the occasional INFRA requests than having to install patches, monitoring etc. myself. GitLab uses a normal git file-based storage for the repositories, so it should be possible for that file system to be the same one uses by git-wip-us (although git over NFS should raise alarm bells..) I agree with Roman that the social benefit from Github happens at Github - and the pull request integration is a great path into the project for outsiders. ..but that doesn't mean we have to submit totally to Github for normal use of the source code. I believe Gitlab allows sign-in by GitHub id - but I am not so sure about automatic mirroring from Gitlab to GitHub (or pull request integration back again). This could still be achieved the classic way if the repositories remains at git-wip-us. The GitLab issue tracker (which looks very much like GitHub's issue tracker) is an ideal tracker for many projects - not as complex as Jira, and not as arcane as Bugzilla. I have not tested it in detail, but if it has similar email integration as GitHub, then it becomes a smooth integration with the dev@ lists as well. With the GitHub/GitLab style of working you also tend to make several smaller repositories rather than a monolithic $project.git. With a web interface like Gitlab Enterprise, in theory the PMC chairs can be granted karma to click the Create button for their project rather than having to wait for INFRA to run a series of scripts. Now browsing of git repositories is my bugbear.. In my own developer documentation I like to deep-link to the relevant source code rather than just talk about things in the abstract or with Javadoc links - this becomes then also an invitation to explore the code and to contribute. With our own git infrastructure there is not really a usable Browse function - see for example: https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git - Where is the code? Oh, you have to click Tree. - How do I deep-link to code from our website and emails? Links like https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=blob;f=taverna-scufl2-api/src/main/java/org/apache/taverna/scufl2/api/io/WorkflowBundleIO.java;h=03bf3d1ece6674c97747612223f04e3fcd1802fd;hb=de2d370db6f037afa21ca10c3a51f2192aaaddc5 seem unpredictable and are hard to use. - How do I even check out? Do some regular expressions in your head from the current URL. - How do I navigate the code? I have to click manually on README.md files - which are not rendered as Markdown Thus every project has to write a lot of documentation with basic information like how to clone a repository and how to navigate the code base -- or simply send people off to Github (which borders onto product endorsement) and use Apache's git infrastructure as a write-only service. I would consider browsing of the code to be essential for being open for outsiders. Apache insiders will know how to navigate these things, or know when to use Github mirrors - but for anyone incubating into Apache or bumping into an Apache project, being sent into the git-wip-us interface basically looks like Go away. So as Apache is all about the community - we should consider: 1) Github presence is essential 2) Browsing code is essential 3) Apache-controlled infrastructure should be used for day-to-day running of a project Very nice summary, Stain! I agree with you. On 5 March 2015 at 08:15, Niclas Hedhman nic...@hedhman.org wrote: Yes, the network effect is important, but is it the only one? Can the network effect happen on ASF systems? Would we want it to? // Niclas On Thu, Mar 5, 2015 at 1:43 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Wed, Mar 4, 2015 at 7:24 PM, Niclas Hedhman nic...@hedhman.org wrote: But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Here's the way I look at it: the power of github.com comes not so much from the web UI or even API, but from a network effect. It is where developers congregate. Thus we'd have to have mirrors of our stuff there anyway to enable PR workflow for
Re: GitLab?
On Thu, Mar 5, 2015 at 6:43 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Wed, Mar 4, 2015 at 7:24 PM, Niclas Hedhman nic...@hedhman.org wrote: But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Here's the way I look at it: the power of github.com comes not so much from the web UI or even API, but from a network effect. It is where developers congregate. Github without the web ui or the api wouldn't have the same effect as it has, it would basically be what we currently have.. By providing a similar service there's nothing that stops git.apache.org (or whatever hostname gitlab would have) to become the new ground where collaboration on Apache projects happen. I've worked on projects residing on gitlab.com without thinking much about it being there rather than on github. -- Erik
Re: Apache Reporter Service
On 2015-03-05 01:00, sebb wrote: On 4 March 2015 at 07:26, Daniel Gruno humbed...@apache.org wrote: On 2015-03-04 01:29, sebb wrote: The tool looks cool, but does not handle Apache Commons properly, as it calls it Apache Commons BeanUtils. BeanUtils is just one of the Commons components (it seems to be picking the first component alphabetically). This was due to Commons not having any information on the base project available in rdf/json, so the system picked what it thought looked like a winner. I have since changed it to just fetch the name from the PMC data instead. The JIRA release option does not work well for Commons. Each component has a separate JIRA id, but the graph does not show the id. There are other TLPs with multiple JIRA instances and release cycles, for example Creadur The JIRA stats are in their infancy still, I'll see if I can't make it more useful for Commons this week. The JIRA release fetch tool does not report an error for an invalid JIRA id. Note that all Commons JIRA ids are in the Category Commons; similarly all Creadur instances are in the Category Creadur. It would be really useful if the releases could be fetched using the Category. I am on the PMC for Commons, JMeter and Creadur. Only the JMeter display shows the chair person. fixed for comons. As for Creadur, whenever someone creates a profile for the How does one create profiles? Nothing obvious on the website. One clicks on the editor icon to the far right of the menu bar. UI patches are most welcome :) project on projects-new.apache.org, the data will automatically start projects-new shows Apache Commons BeanUtils: 121 committers, 35 PMC members = sub-project It does not make sense to include sub-projects in the project list. showing up on reporter.a.o. That seems to have been done. Might be useful to cross-link the two apps and provide some background docs on how to use them. It would be useful if ASF members could see the data for every PMC - but obviously not update PMCs they are not associated with. That is how it already is. Use the hot-link feature to access projects you are not on the PMC of, or use the 'statistics' link from Whimsy. What hot-link feature? I only see tabs for the 3 PMCs I am on. If you use the whimsy agenda browser, there is a link under info - statistics for each PMC that leads to reporter.apache.org and shows you information about that PMC as well. You can also access this manually by going to https://reporter.apache.org/?pmcid (where pmcid is the LDAP ID of the PMC, for instance apr, httpd, sling, climate etc). With regards, Daniel. With regards, Daniel. On 3 March 2015 at 10:50, Daniel Gruno humbed...@apache.org wrote: Hi folks, as some of you will have noticed, either by the commits I just made or conversations going on elsewhere, I have started work on a new helper system for PMCs called the Apache Reporter Service. This is sort of an external addition to Whimsy, and shows various statistics and data for projects, designed to aid chairs (and other lurkers) in viewing and compiling data for board reports. The system is now live at: https://reporter.apache.org - you will need to be a PMC member of a project to view this site, and you will - in general - only be shown data for projects where you are on the PMC. The system will show you: - Your next report date and the chair of the project - PMC and committership changes over the past 3 months, as well as latest additions if 3 months ago - The latest releases done this quarter (if added by RMs) - Mailing list statistics: number of subscribers as well as number of emails sent this quarter and the previous - JIRA tickets opened/closed this quarter (if correctly mapped within the system) - A mock-up of a board report, with the above data compiled into it (to be edited heavily by the chair!) Quick-navigation (hot-links) can be done by using the LDAP name of a project in the URL, for instance: https://reporter.apache.org/?apr would navigate directly to the Apache Portable Runtime project if you are on that PMC (or a member of the foundation). The report mock-up is meant as a help only, not a canonical template for board reports. Vital items, such as community activity and board issues are intentionally left for the reporter (chair) to fill out, and heaven help the woman/man who submits a report with these fields left as default ;). Later today, I plan to enable the distribution watching part of this service, which will send reminders to anyone who pushes a release, that they should (not required, but if they want to!) add their release data to the system, so as to help others using the system to get an overview of the status of any given project. I have already gotten a lot of really useful feedback, but if you see something you'd like to change, either shoot me an email here on the comdev list, or commit a change to the system in svn. With regards, Daniel.
Re: GitLab?
I'm a long-time CVS/SVN user (multiple decades), and I started using git and github about a year-and-a-half ago for a non-ASF project intermittently. While I like the parallel development paths, merging, and speed that git provides, the integrated bug tracking, code commenting, code browsing, and low cost of entry as a new user in github really added to the community building of the project. Achim Nierbeck and Stian Soiland-Reyes are correct when they say that git without github loses a great deal of the full user experience of working in this kind of environment and I doubt I would have been pulled into that project's community and development nearly so much if github had not been part of the equation. I'd rather seen Infra start the ball rolling to provide an official github alternative than see a bunch of projects build their own services. First, I think that the value of a fully-functional github service is already proven. That's why every ASF git project also has a github mirror. Second, github doesn't just build community internally to a project but also builds community between projects which is an ASF goal. You tend to jump from one project to another related project when code browsing. Third, the adoption of a github service is inevitable anyway :) Even as a new git user, when my ASF projects started supporting git, my first thought was Where's the github service alternative? On Thu, Mar 5, 2015 at 6:44 AM, Achim Nierbeck bcanh...@googlemail.com wrote: Hi, just my 2 cents, something like that would really improve the user-experience compared to what we have right now. :-) I'm very thankfull that we have a git repo already but something eye-candy like what is possible with that gitlab stuff seems very charming to me. In that case I'd rather use links to those pages for discussing certain code-snippets with other instead of what I do now, use a link to the github project. I think this is the last missing piece to get a good user-experience for those github spoiled people out there :-) regards, Achim 2015-03-05 12:09 GMT+01:00 Benedikt Ritter brit...@apache.org: 2015-03-05 11:51 GMT+01:00 Stian Soiland-Reyes st...@apache.org: I think it would be interesting to do a trial, perhaps with a couple of willingnew projects. How would you rally projects together to demand it before seeing what it would be like? For me personally, not having to manage VMs with development infrastructure is one additional advantage of moving to Apache - I'm OK to wait for the occasional INFRA requests than having to install patches, monitoring etc. myself. GitLab uses a normal git file-based storage for the repositories, so it should be possible for that file system to be the same one uses by git-wip-us (although git over NFS should raise alarm bells..) I agree with Roman that the social benefit from Github happens at Github - and the pull request integration is a great path into the project for outsiders. ..but that doesn't mean we have to submit totally to Github for normal use of the source code. I believe Gitlab allows sign-in by GitHub id - but I am not so sure about automatic mirroring from Gitlab to GitHub (or pull request integration back again). This could still be achieved the classic way if the repositories remains at git-wip-us. The GitLab issue tracker (which looks very much like GitHub's issue tracker) is an ideal tracker for many projects - not as complex as Jira, and not as arcane as Bugzilla. I have not tested it in detail, but if it has similar email integration as GitHub, then it becomes a smooth integration with the dev@ lists as well. With the GitHub/GitLab style of working you also tend to make several smaller repositories rather than a monolithic $project.git. With a web interface like Gitlab Enterprise, in theory the PMC chairs can be granted karma to click the Create button for their project rather than having to wait for INFRA to run a series of scripts. Now browsing of git repositories is my bugbear.. In my own developer documentation I like to deep-link to the relevant source code rather than just talk about things in the abstract or with Javadoc links - this becomes then also an invitation to explore the code and to contribute. With our own git infrastructure there is not really a usable Browse function - see for example: https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git - Where is the code? Oh, you have to click Tree. - How do I deep-link to code from our website and emails? Links like https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=blob;f=taverna-scufl2-api/src/main/java/org/apache/taverna/scufl2/api/io/WorkflowBundleIO.java;h=03bf3d1ece6674c97747612223f04e3fcd1802fd;hb=de2d370db6f037afa21ca10c3a51f2192aaaddc5 seem unpredictable and are hard to use. - How do I even check out? Do
Re: GitLab?
I do feel the need to remind people that there is also Apache Allura, which provides a comprehensive development environment, in fact, more comprehensive than GitHub or GitLab. Plus, last I checked, the PMC was working w/ Infra to ensure that should Allura be installed, there would be people *supporting* the install.
Re: GitLab?
On Thu, Mar 5, 2015 at 7:27 AM Mike Kienenberger mkien...@gmail.com wrote: I'm a long-time CVS/SVN user (multiple decades), and I started using git and github about a year-and-a-half ago for a non-ASF project intermittently. While I like the parallel development paths, merging, and speed that git provides, the integrated bug tracking, code commenting, code browsing, and low cost of entry as a new user in github really added to the community building of the project. Achim Nierbeck and Stian Soiland-Reyes are correct when they say that git without github loses a great deal of the full user experience of working in this kind of environment and I doubt I would have been pulled into that project's community and development nearly so much if github had not been part of the equation. I think when I read statements like this, it reminds me of one of those classic this tool fixes everything types of notes. It's not the fact that you have github that things are better, but the sheer fact that you have a way to support external contributions in a more streamlined way. I see projects today in ASF that use git, but apply external changes via patch files. That part boggles my mind. There are lots of tools like github out there. Heck, you could probably even automate ICLAs with a custom license agreement. I'd rather seen Infra start the ball rolling to provide an official github alternative than see a bunch of projects build their own services. First, I think that the value of a fully-functional github service is already proven. That's why every ASF git project also has a github mirror. Second, github doesn't just build community internally to a project but also builds community between projects which is an ASF goal. You tend to jump from one project to another related project when code browsing. Third, the adoption of a github service is inevitable anyway :) Even as a new git user, when my ASF projects started supporting git, my first thought was Where's the github service alternative? On Thu, Mar 5, 2015 at 6:44 AM, Achim Nierbeck bcanh...@googlemail.com wrote: Hi, just my 2 cents, something like that would really improve the user-experience compared to what we have right now. :-) I'm very thankfull that we have a git repo already but something eye-candy like what is possible with that gitlab stuff seems very charming to me. In that case I'd rather use links to those pages for discussing certain code-snippets with other instead of what I do now, use a link to the github project. I think this is the last missing piece to get a good user-experience for those github spoiled people out there :-) regards, Achim 2015-03-05 12:09 GMT+01:00 Benedikt Ritter brit...@apache.org: 2015-03-05 11:51 GMT+01:00 Stian Soiland-Reyes st...@apache.org: I think it would be interesting to do a trial, perhaps with a couple of willingnew projects. How would you rally projects together to demand it before seeing what it would be like? For me personally, not having to manage VMs with development infrastructure is one additional advantage of moving to Apache - I'm OK to wait for the occasional INFRA requests than having to install patches, monitoring etc. myself. GitLab uses a normal git file-based storage for the repositories, so it should be possible for that file system to be the same one uses by git-wip-us (although git over NFS should raise alarm bells..) I agree with Roman that the social benefit from Github happens at Github - and the pull request integration is a great path into the project for outsiders. ..but that doesn't mean we have to submit totally to Github for normal use of the source code. I believe Gitlab allows sign-in by GitHub id - but I am not so sure about automatic mirroring from Gitlab to GitHub (or pull request integration back again). This could still be achieved the classic way if the repositories remains at git-wip-us. The GitLab issue tracker (which looks very much like GitHub's issue tracker) is an ideal tracker for many projects - not as complex as Jira, and not as arcane as Bugzilla. I have not tested it in detail, but if it has similar email integration as GitHub, then it becomes a smooth integration with the dev@ lists as well. With the GitHub/GitLab style of working you also tend to make several smaller repositories rather than a monolithic $project.git. With a web interface like Gitlab Enterprise, in theory the PMC chairs can be granted karma to click the Create button for their project rather than having to wait for INFRA to run a series of scripts. Now browsing of git repositories is my bugbear.. In my own developer documentation I like to deep-link to the relevant source code rather than just talk about things in the abstract or with Javadoc links - this becomes
Re: GitLab?
On Wed, Mar 4, 2015 at 10:24 PM, Niclas Hedhman nic...@hedhman.org wrote: Opening a new thread... Git without Github is like sex without a partner, sufficient but not very satisfactory. Github option has been explored in the past, and due to various reasons, it was not possible to achieve. But, during my last 2-3 year absence, has the GitLab[1] option been discussed and/or tried? GitLab is open sourced, can run on our infra and has many of the essential features of Github. But perhaps people are satisfied enough with the Github mirroring that is already in place, but with GitLab in house, we could (in theory) add features around licensing (like ICLA style assurance, similar to Jira), and non-committers could(!) be allowed a direct route to the horse's mouth... Although the Enterprise system cost money, my guess is that GitLab would be happy to waive fees and give us access to EE. Just a thought. [1] https://about.gitlab.com/features/ -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java Infrastructure (at least in the short term) won't deploy Gitlab. The reasoning is this: 1. Most of our demand from projects is for Github, and truthfully, if we could resolve one or two nagging problems, Infra would love to no longer run and administer several hundred git repositories and instead offload that work to Github. 2. There is a lot of infrastructure built up around the existing git infrastructure. Deploying Gitlab or Allura or anything else would require us to figure out authorization, backups, integration with Github, Jira, BZ, svn mirroring, etc; that's a lot of work. IF we were going to tackle such a project it would need to be for all projects, not just a few, and it would be significantly lower on the priority list than a lot of the work we are currently doing. My current thinking (though not yet Foundation policy) is that there is the canonical repository must be managed by Infra, and I suspect that will be in the proposed policy that gets submitted to the board. --David