Re: [PATCH 6/6] GITWEB - Separate defaults from main file
- From
J.H. <warthog9@kernel.org>
- Date
- Dec 16, 2009, 02:00 UTC
- Message-ID
- <4B283F3D.3020209@kernel.org>
- In-Reply-To
- <7v8wd3ww4d.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 24 quoted lines
> Jakub Narebski <jnareb@gmail.com> 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.
Show 10 quoted lines
> 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?