Hi all,
What if any plans are in the pipeline for improving the web front-end of git.centos.org?
Current issues:
* Slow.
* No search as page claims:
none of your repositories are configured for Lucene indexing
* Clicking on the 'repositories' link, hangs firefox because of how many entries are being listed by default. Could this be a static page with alphanumeric index that a user can click on depending on first character of package they wish to find?
Regards
Phil
On 24/03/16 08:39, Phil Wyett wrote:
Hi all,
What if any plans are in the pipeline for improving the web front-end of git.centos.org?
Current issues:
Slow.
No search as page claims:
none of your repositories are configured for Lucene indexing
Clicking on the 'repositories' link, hangs firefox because of how many entries are being listed by default. Could this be a static page with alphanumeric index that a user can click on depending on first character of package they wish to find?
unfortunately, there isnt much else that offers us the capabilities we need. I've been looking these last few weeks for alternatives and they all come up short.
but there are plans to spend a bit of time and see what / where we might be able to make improvements.
the lucene index would come into play if you wanted to search in the actual git objects, is that what you are looking for ?
regards
On Thu, 2016-03-24 at 08:42 +0000, Karanbir Singh wrote:
On 24/03/16 08:39, Phil Wyett wrote:
Hi all,
What if any plans are in the pipeline for improving the web front-end of git.centos.org?
Current issues:
Slow.
No search as page claims:
none of your repositories are configured for Lucene indexing
Clicking on the 'repositories' link, hangs firefox because of how many entries are being listed by default. Could this be a static page with alphanumeric index that a user can click on depending on first character of package they wish to find?
unfortunately, there isnt much else that offers us the capabilities we need. I've been looking these last few weeks for alternatives and they all come up short.
but there are plans to spend a bit of time and see what / where we might be able to make improvements.
the lucene index would come into play if you wanted to search in the actual git objects, is that what you are looking for ?
regards
Hi,
For most scenarios, I would just pull a complete package repo. My main use of the web interface is often research and the quick viewing of a specific file e.g. looking at spec files for changes and how I may clean up the way I do things / keep to current convention.
For now I will just bypass the navigation and just do:
https://git.centos.org/summary/!!!!!!rpms!<package_name_I_want>.git
to view a specific repos.
Regards
Phil
On 24/03/16 09:11, Phil Wyett wrote:
For now I will just bypass the navigation and just do:
https://git.centos.org/summary/!!!!!!rpms!<package_name_I_want>.git
The !'s is unfortunate :/ but fixable in the short term.
to view a specific repos.
On 24/03/2016 08:42, Karanbir Singh wrote:
unfortunately, there isnt much else that offers us the capabilities we need. I've been looking these last few weeks for alternatives and they all come up short.
Is there a list of these requirements somewhere?
A thought at the back of my mind whenever git.centos.org is mentioned is that there's a lot of 3rd parties that now rely on it as the source for RHEL 7, and many of them will have scripts around gitblit's current setup. Any changes to g.c.o that would impact those scripts would need to be carefully rolled out with appropriate public notice.
On 24/03/16 09:53, Howard Johnson wrote:
On 24/03/2016 08:42, Karanbir Singh wrote:
unfortunately, there isnt much else that offers us the capabilities we need. I've been looking these last few weeks for alternatives and they all come up short.
Is there a list of these requirements somewhere?
A thought at the back of my mind whenever git.centos.org is mentioned is that there's a lot of 3rd parties that now rely on it as the source for RHEL 7, and many of them will have scripts around gitblit's current setup. Any changes to g.c.o that would impact those scripts would need to be carefully rolled out with appropriate public notice.
One of the key things to chose Gitblit was the api and automation folks can run against it - there are no plans on changing that.