Petr Baudis wrote:
On very large sites like repo.or.cz (but maybe also git.debian.org, git.kernel.org, etc.),
I think between our own caching (which I'll be submitting a cleaned up patch for here shortly for mainline inclusion) and our users want to *NOT* deal with searching or pagination this actually isn't that useful to us, despite having a signifigant number of projects, and the front page (at leas for us) only weighing in at 567,710bytes means that we are moving less data to show the git.kernel.org page than facebook does to show their home screen (I.E. anything modern can trivially cope with that)
it is desirable not to have the project list on the front page since generating it is significant overhead and it takes significant data transfer and load time for the user, who might prefer to instead use the search form and possibly content tags to navigate to the target project. A link to the full list of projects is still available on the front page for users who wish to browse it. The whole feature is turned off by default. The patch introduces a new config variable $frontpage_no_project_list, by default 0 keeping the current behavior; if set to 1, no project list will be shown, but all projects will be still scanned if ctags are enabled; if set to 2, no project will be shown and no projects will be scanned while showing the front page. The compromise value of 1 is useful for sites where project scan time is not an issue or which use additional project list caching patches.
I question the need for 0,1,2. If the site doesn't want something like the tag cloud they are already going to turn it off with the normal cloud system. I think this should be either a bitmask or an array to explicitly turn particular things on or off, or a binary value that would *ONLY* deal with showing the project listing.
- John 'Warthog9' Hawley -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html