From: J.H. Date: Wed, 16 Dec 2009 02:00:29 GMT Subject: Re: [PATCH 6/6] GITWEB - Separate defaults from main file Message-ID: <4B283F3D.3020209@kernel.org> In-Reply-To: <7v8wd3ww4d.fsf@alter.siamese.dyndns.org> Junio C Hamano wrote: > Jakub Narebski writes: > >> On Fri, 11 Dec 2009, J.H. wrote: >> >>>>> This is also a not-so-subtle start of trying to break up gitweb into >>>>> separate files for easier maintainability, having everything in a >>>>> single file is just a mess and makes the whole thing more complicated >>>>> than it needs to be. This is a bit of a baby step towards breaking it >>>>> up for easier maintenance. >>>> The question is if easier maintenance and development by spliting >>>> gitweb for developers offsets ease of install for users. >>> This would just get dropped into the same location that gitweb.cgi >>> exists in, there is no real difference in installation, and thus I can't >>> see this as an issue for users. >> To be more exact you have to know that you have to drop _generated files_, >> which means (for this version of patch) gitweb.cgi and gitweb_defaults.pl >> (or whatever the generated file with config variables would be named). >> >> >> ATTENTION! > > You didn't have to shout. > > Any progress on this front? Sadly, no. Busy weekend and a need to get some of the kernel.org servers upgraded has taken some precedence. I should be circling back around on this tomorrow I think. > Not that I am anxious to queue new topics to 'next' right now (we are > frozen for 1.6.6), but I think having what is proven to work well at a > real site like k.org is much better than waiting for an unproven > reimplementation using somebody else's framework only for your theoretical > cleanliness. John has better things to do than doing such a rewrite > himself, and even if you helped the process by producing a competing > caching scheme based on existing web caching engines, the aggregated > result (not just the web caching engine you base your work on) needs to > get a similar field exposure to prove itself that it can scale to the load > k.org sees, which would be quite a lot of work, no?