On Tue, Apr 20, 2010 at 4:44 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > On Mon, 19 April 2010, Pavan Kumar Sunkara wrote: >> 2010/4/19 Jakub Narebski <jnareb@xxxxxxxxx>: >>> On Mon, 19 Apr 2010, Pavan Kumar Sunkara wrote: >>>> On Mon, Apr 19, 2010 at 2:52 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > >>> >>> I can agree that you would be able to learn Perl in a week. I do not >>> think however that you can become proficient in Perl (and neither in any >>> other non-trivial programming language) in such short time. The question >>> remains if you can be proficient enough for the task in question... >> >> I can learn perl in 3 hours. Becoming proficient in perl is just >> knowing about all the majorly used inbuilt functions and libraries. >> Coming to the concepts of programming, I already know a lot about it >> along with data structures and algortihms. So you need not doubt me on >> this. > > You can (probably) learn Perl *syntax* in 3 hours. You perhaps can > learn to start to write clean, idiomatic Perl within a week, provided > that you find good books (like "Higher-Order Perl", which can be found > at http://hop.perl.plover.com/book/, or other Perl books from O'Reilly). > Be proficient in Perl in that short time? I don't think so. > > I guess that you can learn enough Perl for this project, but I'd really > prefer for you to be proficient in Perl already... It's your choice. All I can say is learning perl won't be a obstruction to do this project. >>> >>> Yes, I found it in later parts of proposal, but don't you think that >>> this goal of this project should be stated upfront, so that one can >>> know what this project is to be about from project description itself? >> >> I thought it should be described later in the "Describe your project >> in more detail" section. So, I didn't go into details here. > > Nevetheless it is a place to describe *specific* goal of project here, > in one to two sentences. No marketing buzzwords here :-PPP :-) >>> >>> I guess (please correct me if I am wrong) that lib/ would contain modules >>> *required* by gitweb, and modules/ would contain *optional* modules >>> needed for extra functionality (for extra features). >> >> You are half correct. >> lib/ contains modules *required* by gitweb >> modules/ contains actions *performed* in gitweb like commitlog, >> snapshot etc.. (write actions too) >> >> Maybe I will rename it to actions/ to not to be confused. > > I don't understand why actions are not to be in lib/, like e.g. SVN::Web > (http://p3rl.org/SVN::Web) has SVN::Web::Blame module for 'blame' action? > Although I am not sure if SVN::Web is a good example of coding practices > and code organization. I did so to make them clearly distinct and easily to be maintain and modify later. >>> >>> If gitweb is configured to scan for repositories, adding existing git >>> repository to gitweb doesn't make sense. If gitweb is configured to >>> use static file with list of repositories, of course it would make >>> sense... but then the question is how would one specify location of >>> a new repository to add. >> >> How about like this ? >> We will have a static file with list of projects. All the repositories >> in scan path will be added to this list. Then we will also have an >> option to add an existing repository which can be done when the user >> specifies a relative or full path to the repository. > > O.K. that is a good idea: make gitweb scan for repositories, and present > user with the list of them to add to static list of visible projects > (repositories). ok. >>> >>> Well, unless there would be time for it after you finish all other work, >>> but it is a bit unlikely. >> >> I don't think so. I would like to constantly contribute to gitweb. > > I'm sorry, we seem to have a bit of misunderstanding here. What I meant > that this should be in the "optional" part of GSoC project, so it would > be worked on during GSoC only after everything else is done. Because the > scope of this project is quite wide, I though it unlikely to have time > left at the end of GSoC after finishing all other more important features. > > I did not mean to say that you would be unlikely to contribute after GSoC > finishes. ok. I can include it is an option part of GSoC. Thanks -pavan -- 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