threads / discuss / 12483

GSoC 2008 - Mentors Wanted!

Subject: GSoC 2008 - Mentors Wanted!

## tl;dr

24 messages between Mar 4, 2008 and Mar 6, 2008.

replies: 23people: 9as markdown or json

Shawn O. Pearce· Mar 4, 2008, 05:11 UTC · lore

As part of our organization application for GSoC 2008 we need to list possible mentors. At this stage of the process it is not a binding commitment. You can offer to be a mentor now and still back out later if the project you are really interested in doesn't get a student, or if your situation changes and you no longer will have the time.

One of the things that will help make our organization application look good to Google this year is having strong community support for GSoC 2008, in the form of having many mentors available for our ideas list. Google can easily determine the size of our mailing list membership (~859 addresses) and it would be nice if we can show better than a 0.23% mentor rate. :-)

Being a mentor will eventually become a binding commitment once we start matching up students<->mentors and we know exactly how many slots Google will offer us. Backing out at this point could cause us to scramble to locate another mentor, or worse, lose the student. That gets set in stone during the week of April 7th - 11th, 2008.

Based on prior GSoC experience (inside and outside of Git) it is estimated that a mentor will need to spend between 5-10 hours per week (~1-2 hours per day) with their student, over email, IRC, etc. to help guide the student through their project. Projects run from May 26th through August 11th.

OK, enough, onto the project list!
  http://git.or.cz/gitwiki/SoC2008Ideas

That is only a starting list of possible projects. At present Dscho and myself are listed as possible mentors for a vast majority of these projects. I'd love to get some more members of the community involved this year.

If you are interested in being a mentor for a GSoC project, please list your name next to the project, and if at all possible an email address so prospective students can contact you. If you have a good project idea in mind, but don't see it on the wiki, please add it!

I would also appreciate it if you can send me your Google Mail account, as we need to list each mentor's Google Mail username in the organzation application. This allows Google to see that we have strong support for GSoC 2008, and gives you access to view the student applications once they start getting submitted.

-- 
Shawn.
Matthieu Moy· Mar 4, 2008, 09:23 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

"Shawn O. Pearce" <spearce@spearce.org> writes:
> OK, enough, onto the project list!
>
>   http://git.or.cz/gitwiki/SoC2008Ideas
Jakub posted an idea about git.el (Emacs support) a few days ago:
Show 17 quoted lines
> * GNU Emacs git GUI
>
>   Make git mode for Emacs full featured git GUI, and not only commit
>   tool, following ideas of PCL-CVS... and its limitation. I guess that
>   DVC (http://download.gna.org/dvc) git mode is one thing to examine
>   searching for features to implement, but from what I have read in
>   documentation it is quite a but GNU Arch centric. Other git GUIs, like
>   git-gui, gitk, qgit, tig could also be inspiration for features.
>
>   Goal: Allow creating and switching branches, examining history,
>   merging, fetching etc. from withing Emacs. Should include modes for
>   git config file forma and format-patch patches.
>
>   Language: Emacs Lisp
>   Suggested mentors:
>     Alexandre Julliard
>     David Kagedal

Since I've been quite involved in DVC in the past, I'm willing to help with this, but unfortunately, I'm swamped with work and I can't commit for ~5-10h/week on that.

So, if someone else steps in, perhaps we could rephrase the subject in a "merge git.el and DVC, and improve it" way, and I could co-mentor this one.

All that said, I think most of the ideas already on the wiki should be prioritized (I love Emacs, but I think more people need a good Windows support/GUI for example).

-- 
Matthieu
Shawn O. Pearce· Mar 5, 2008, 06:06 UTC · re: Matthieu Moy · lore

Re: GSoC 2008 - Mentors Wanted!

Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
Show 6 quoted lines
> Jakub posted an idea about git.el (Emacs support) a few days ago:
> > * GNU Emacs git GUI
> >
> >   Make git mode for Emacs full featured git GUI, and not only commit
> >   tool, following ideas of PCL-CVS... and its limitation. I guess that
> >   DVC (http://download.gna.org/dvc) git mode is one thing to examine
...
Show 8 quoted lines
> 
> Since I've been quite involved in DVC in the past, I'm willing to help
> with this, but unfortunately, I'm swamped with work and I can't commit
> for ~5-10h/week on that.
> 
> So, if someone else steps in, perhaps we could rephrase the subject in
> a "merge git.el and DVC, and improve it" way, and I could co-mentor
> this one.

Thanks. It would be nice to be able to have several mentors per student project, to ease the burden on mentors. But as you go away from the core of git into the less widely used areas (e.g. I am not an emacs user and thus do not touch the emacs git support) its harder to find multiple mentors. Then again, emacs users are a friendly bunch so we might get lucky and have 5 emacs mentors. :)

> All that said, I think most of the ideas already on the wiki should be
> prioritized (I love Emacs, but I think more people need a good Windows
> support/GUI for example).

Yea. But one thing I learned last year from GSoC was that students are likely to come in one of three forms:

  Type a)  Just copy and paste our idea text.
           No thought on their part.
  Type b)  Actually think about our idea text and expand upon it.
  Type c)  Come up with their own really cool project idea.

Type c is what you really want, especially if the project idea is well thought out by the student. Type b is a close second. Last year's students were all in this category. Type a, well, we had a number of type a applications last year. Most orgs do.

In short, prioritizing this list doesn't really offer any great value to us. Not until we are actually faced with student applications we like and we have to decide which ones get slots, and which don't.

-- 
Shawn.
Jakub Narebski· Mar 4, 2008, 17:14 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

"Shawn O. Pearce" <spearce@spearce.org> writes:
> That is only a starting list of possible projects.  At present Dscho
> and myself are listed as possible mentors for a vast majority of
> these projects.  I'd love to get some more members of the community
> involved this year.

I could be co-mentor for adding caching support to mainline gitweb. I think I wouldn't have enough time for being full mentor; additionally I don't know enough about HTTP / web caching to help. I know gitweb fairly well, though.

I have CC-ed John 'Warthog9' Hawley (wrote caching for kernel.org's gitweb), as a best candidate for mentor for this project, but I'm not sure if he wouldn't be too busy for mentoring.

-- 
Jakub Narebski
Poland
ShadeHawk on #git
Carlos Rica· Mar 4, 2008, 20:47 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>  OK, enough, onto the project list!
>
>   http://git.or.cz/gitwiki/SoC2008Ideas

Gitster talked today about libification as a project for the GSoC (I mangled some comments, I accept complaints):

gitster> For the record, i've never said I am not interested in libification.
gitster> However.

gitster> (1) I know of many places whose design is based on run-once-and-exit, and that was done for very good reasons (simpler clean-up, no risk of reusing stale data, simpler codepath in general), and

cehteh> gitster: yes anyone is interested .. i rather meant it would be nice if you and others make it primary concern for accepting patches/future development imo .. but well yes still your decision, just a mild critic

* cehteh currently uses libgit and doesnt really feel comfortable with it

gitster> (2) cleaning up to make functions re-entrant can happen incrementally, but should not have horrible performance issues for run-once-and-exit users --- see what we did to libify merge_base(), for example, as that one is done the right way;

cehteh> yes

cehteh> we could even #ifdef LIBGIT or such for cleanup/reentrancy stuff .. but someone has to lead supervise that, and others shouldent throw bricks in the way which still sometimes happens

gitster> (3) and I know it would be a very large effort to do it all, so a project that can be described with an umbrella "libification" name would exceed GSoC size.

gitster> (4) and "should not" list in (2) includes maintainability. Mindless #ifdefs are out.

gitster> So, I would not oppose it, but I just warn anybody that this is a long term subproject. I won't have time to commit myself on it, unless everybody will be happy not to see any new developments merged outside libification, that is.

gitster> So "libify merge-base" would have been a focused and well defined subproject of GSoC size. "libification" is not.

cehteh> ack
gitster> So was "libify the active_cache[] access".

gitster> "rewrite git-submodule, put the repository for submodules in the superproject $GIT_DIR/modules, and use .git-file (currently in 'pu') to point at it", would be a good sized one.

gitster> "refine diffcore-rename to add a postprocessing phase so that if we find rename from i386/foo.c to x86/foo.c but i386/bar.c was rewritten too much and did not match new x86/bar.c make them match" would be a good one as well. Throw in "refine diffcore-rename further so that it can tell a whole directory movement by summarizing the constituent files' movement" and you will get a gold star ;-)

gitster> "teach 3-way fallback logic git-am has to git-apply".
....
Carlos Rica· Mar 4, 2008, 20:51 UTC · re: Carlos Rica · lore

Re: GSoC 2008 - Mentors Wanted!

On Tue, Mar 4, 2008 at 9:47 PM, Carlos Rica <jasampler@gmail.com> wrote:
>  Gitster talked today about libification as a project for the GSoC
>  (I mangled some comments, I accept complaints):

I mean, I removed some comments from the start, middle and end of the conversation. The order and comments are left as it was.

-- Carlos

Shawn O. Pearce· Mar 5, 2008, 05:36 UTC · re: Carlos Rica · lore

Re: GSoC 2008 - Mentors Wanted!

Carlos Rica <jasampler@gmail.com> wrote:
Show 7 quoted lines
> On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> >  OK, enough, onto the project list!
> >
> >   http://git.or.cz/gitwiki/SoC2008Ideas
> 
> Gitster talked today about libification as a project for the GSoC
> (I mangled some comments, I accept complaints):
Thanks for pasting this chunk of the log Carlos.  I otherwise would
have certainly missed it.  Much appreciated.
 
> gitster> For the record, i've never said I am not interested in libification.
> 
> gitster> However.
[... lots of good gitster remarks removed for space ...]

After some reflection I agree with Junio. As such I have moved the libification project down the page to a new category, "Projects So Large Your Head Will Spin".

> gitster> "rewrite git-submodule, put the repository for submodules in
> the superproject $GIT_DIR/modules, and use .git-file (currently in
> 'pu') to point at it", would be a good sized one.
...
> gitster> "teach 3-way fallback logic git-am has to git-apply".

These have gone onto the list as smaller, more average sized projects. Both are interesting and useful. Thanks Junio.

-- 
Shawn.
Imran M Yousuf· Mar 5, 2008, 07:58 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

I would like to suggest 2 projects that I want to work as a developer (and/or mentor):

1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
The aim of the plugin is to integrate GIT with NetBeans using JNI so
that any change in the implementation of GIT does not effect the SCM
plugins way of work.
Language: Java
Goal: Make GIT available from IDE for NetBeans users and use GIT using
Java Native Interfaces
2. distributed versioned web system backup and restoration framework
(GPLv2 with CPE, same as NetBeans)
[I am not sure whether this one is even qualifies or not as a GIT
Community Project]
Language: Java, NetBeans RCP
Goal: Develop a framework which can backup and restore data from
different components of web application. For example, database, ldap,
log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally
allow edit and propagation of configuration in distributed nature,
system restart, data restore. Also integrate backup and repo maintain
to Amazon S3.
I would be grateful if others would express their opinion about them.
Thank you and best regards,
Imran
On Wed, Mar 5, 2008 at 11:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 44 quoted lines
> Carlos Rica <jasampler@gmail.com> wrote:
>
> > On Tue, Mar 4, 2008 at 6:11 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>  > >  OK, enough, onto the project list!
>  > >
>  > >   http://git.or.cz/gitwiki/SoC2008Ideas
>  >
>  > Gitster talked today about libification as a project for the GSoC
>  > (I mangled some comments, I accept complaints):
>
>  Thanks for pasting this chunk of the log Carlos.  I otherwise would
>  have certainly missed it.  Much appreciated.
>
>
>  > gitster> For the record, i've never said I am not interested in libification.
>  >
>  > gitster> However.
>
>  [... lots of good gitster remarks removed for space ...]
>
>  After some reflection I agree with Junio.  As such I have moved the
>  libification project down the page to a new category, "Projects So
>  Large Your Head Will Spin".
>
>
>  > gitster> "rewrite git-submodule, put the repository for submodules in
>  > the superproject $GIT_DIR/modules, and use .git-file (currently in
>  > 'pu') to point at it", would be a good sized one.
>  ...
>
> > gitster> "teach 3-way fallback logic git-am has to git-apply".
>
>  These have gone onto the list as smaller, more average sized
>  projects.  Both are interesting and useful.  Thanks Junio.
>
>  --
>  Shawn.
>
>
> --
>  To unsubscribe from this list: send the line "unsubscribe git" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
Shawn O. Pearce· Mar 5, 2008, 08:15 UTC · re: Imran M Yousuf · lore

Re: GSoC 2008 - Mentors Wanted!

Imran M Yousuf <imyousuf@gmail.com> wrote:
Show 7 quoted lines
> 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
> The aim of the plugin is to integrate GIT with NetBeans using JNI so
> that any change in the implementation of GIT does not effect the SCM
> plugins way of work.
> Language: Java
> Goal: Make GIT available from IDE for NetBeans users and use GIT using
> Java Native Interfaces

Interesting, but libgit.a is *not* suitable for embedding inside of a JVM. Its no fun when a low level Git function suddenly calls die() because it was fed invalid user input like a mistyped branch name. Your whole IDE shutsdown without a chance to save files.

So that leaves you with three possible routes:
  * Use JNI and libgit.a
    Now you have three projects, not one.  You first need to make
    libgit.a embeddable.  *Then* you can work on a JNI wrapper,
    and finally you can build the UI.
  * Use jgit
    Its at least 100% pure Java and doesn't have the libgit.a issues
    I mentioned above.  Its also got some active developers and its
    userbase is growing.  We have been careful to keep jgit such
    that it runs on any J2SE system, and thus does not require an
    Eclipse environment.
  * Use java.lang.Process and pipes
    Ick.  Forking a running JVM, especially one the size of an IDE,
    is not pretty.  At least on Windows you have CreateProcess(),
    but on POSIX systems the JVM still does a fork/exec pair, and
    on Solaris that hurts hard when your address space is large.
Of these only the latter two are really viable for any time to come
(just my opinion, but that's that).  jgit is coming along and may
actually be able to do most of the critical features that an IDE
demands, especially if more people work on it.  The latter option
is obviously available today, but doesn't offer anything near the
performance or integration that jgit does.
Show 11 quoted lines
> 2. distributed versioned web system backup and restoration framework
> (GPLv2 with CPE, same as NetBeans)
> [I am not sure whether this one is even qualifies or not as a GIT
> Community Project]
> Language: Java, NetBeans RCP
> Goal: Develop a framework which can backup and restore data from
> different components of web application. For example, database, ldap,
> log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally
> allow edit and propagation of configuration in distributed nature,
> system restart, data restore. Also integrate backup and repo maintain
> to Amazon S3.
Yea, I'm not sure this falls too well under the Git community either.
I don't doubt that we would have sufficient mentor experience here
to support such a project, but the outcome in terms of both code and
a student who is familiar with it would not benefit Git very well,
if at all.
 
-- 
Shawn.
Imran M Yousuf· Mar 5, 2008, 08:25 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

On Wed, Mar 5, 2008 at 2:15 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 44 quoted lines
> Imran M Yousuf <imyousuf@gmail.com> wrote:
>  > 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
>  > The aim of the plugin is to integrate GIT with NetBeans using JNI so
>  > that any change in the implementation of GIT does not effect the SCM
>  > plugins way of work.
>  > Language: Java
>  > Goal: Make GIT available from IDE for NetBeans users and use GIT using
>  > Java Native Interfaces
>
>  Interesting, but libgit.a is *not* suitable for embedding inside of
>  a JVM.  Its no fun when a low level Git function suddenly calls die()
>  because it was fed invalid user input like a mistyped branch name.
>  Your whole IDE shutsdown without a chance to save files.
>
>  So that leaves you with three possible routes:
>
>   * Use JNI and libgit.a
>
>     Now you have three projects, not one.  You first need to make
>     libgit.a embeddable.  *Then* you can work on a JNI wrapper,
>     and finally you can build the UI.
>
>   * Use jgit
>
>     Its at least 100% pure Java and doesn't have the libgit.a issues
>     I mentioned above.  Its also got some active developers and its
>     userbase is growing.  We have been careful to keep jgit such
>     that it runs on any J2SE system, and thus does not require an
>     Eclipse environment.
>
>   * Use java.lang.Process and pipes
>
>     Ick.  Forking a running JVM, especially one the size of an IDE,
>     is not pretty.  At least on Windows you have CreateProcess(),
>     but on POSIX systems the JVM still does a fork/exec pair, and
>     on Solaris that hurts hard when your address space is large.
>
>  Of these only the latter two are really viable for any time to come
>  (just my opinion, but that's that).  jgit is coming along and may
>  actually be able to do most of the critical features that an IDE
>  demands, especially if more people work on it.  The latter option
>  is obviously available today, but doesn't offer anything near the
>  performance or integration that jgit does.
>

To start with I was actually thinking of JNI + "exec from C". So later when libification is completed we can replace the execs with call to the libs directly instead. Is this a viable fourth option (sorry I forgot to mention it the first time around)?

Show 22 quoted lines
>
>  > 2. distributed versioned web system backup and restoration framework
>  > (GPLv2 with CPE, same as NetBeans)
>  > [I am not sure whether this one is even qualifies or not as a GIT
>  > Community Project]
>  > Language: Java, NetBeans RCP
>  > Goal: Develop a framework which can backup and restore data from
>  > different components of web application. For example, database, ldap,
>  > log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally
>  > allow edit and propagation of configuration in distributed nature,
>  > system restart, data restore. Also integrate backup and repo maintain
>  > to Amazon S3.
>
>  Yea, I'm not sure this falls too well under the Git community either.
>  I don't doubt that we would have sufficient mentor experience here
>  to support such a project, but the outcome in terms of both code and
>  a student who is familiar with it would not benefit Git very well,
>  if at all.
>
>  --
>  Shawn.
>
-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
Imran M Yousuf· Mar 5, 2008, 08:33 UTC · re: Imran M Yousuf · lore

Re: GSoC 2008 - Mentors Wanted!

On Wed, Mar 5, 2008 at 2:25 PM, Imran M Yousuf <imyousuf@gmail.com> wrote:
Show 52 quoted lines
>
> On Wed, Mar 5, 2008 at 2:15 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>  > Imran M Yousuf <imyousuf@gmail.com> wrote:
>  >  > 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
>  >  > The aim of the plugin is to integrate GIT with NetBeans using JNI so
>  >  > that any change in the implementation of GIT does not effect the SCM
>  >  > plugins way of work.
>  >  > Language: Java
>  >  > Goal: Make GIT available from IDE for NetBeans users and use GIT using
>  >  > Java Native Interfaces
>  >
>  >  Interesting, but libgit.a is *not* suitable for embedding inside of
>  >  a JVM.  Its no fun when a low level Git function suddenly calls die()
>  >  because it was fed invalid user input like a mistyped branch name.
>  >  Your whole IDE shutsdown without a chance to save files.
>  >
>  >  So that leaves you with three possible routes:
>  >
>  >   * Use JNI and libgit.a
>  >
>  >     Now you have three projects, not one.  You first need to make
>  >     libgit.a embeddable.  *Then* you can work on a JNI wrapper,
>  >     and finally you can build the UI.
>  >
>  >   * Use jgit
>  >
>  >     Its at least 100% pure Java and doesn't have the libgit.a issues
>  >     I mentioned above.  Its also got some active developers and its
>  >     userbase is growing.  We have been careful to keep jgit such
>  >     that it runs on any J2SE system, and thus does not require an
>  >     Eclipse environment.
>  >
>  >   * Use java.lang.Process and pipes
>  >
>  >     Ick.  Forking a running JVM, especially one the size of an IDE,
>  >     is not pretty.  At least on Windows you have CreateProcess(),
>  >     but on POSIX systems the JVM still does a fork/exec pair, and
>  >     on Solaris that hurts hard when your address space is large.
>  >
>  >  Of these only the latter two are really viable for any time to come
>  >  (just my opinion, but that's that).  jgit is coming along and may
>  >  actually be able to do most of the critical features that an IDE
>  >  demands, especially if more people work on it.  The latter option
>  >  is obviously available today, but doesn't offer anything near the
>  >  performance or integration that jgit does.
>  >
>
>  To start with I was actually thinking of JNI + "exec from C". So later
>  when libification is completed we can replace the execs with call to
>  the libs directly instead. Is this a viable fourth option (sorry I
>  forgot to mention it the first time around)?
>

Just wanted to add that we can also make them 2 separate projects and the reason I wanted to go with JNI is to take advantage of the new developments of GIT without having to change the API (unless a new release of the API all together).

Show 36 quoted lines
>
>  >
>  >  > 2. distributed versioned web system backup and restoration framework
>  >  > (GPLv2 with CPE, same as NetBeans)
>  >  > [I am not sure whether this one is even qualifies or not as a GIT
>  >  > Community Project]
>  >  > Language: Java, NetBeans RCP
>  >  > Goal: Develop a framework which can backup and restore data from
>  >  > different components of web application. For example, database, ldap,
>  >  > log, images, files (PHP, JSP, PY, HTML, JS, CSS etc.). Additionally
>  >  > allow edit and propagation of configuration in distributed nature,
>  >  > system restart, data restore. Also integrate backup and repo maintain
>  >  > to Amazon S3.
>  >
>  >  Yea, I'm not sure this falls too well under the Git community either.
>  >  I don't doubt that we would have sufficient mentor experience here
>  >  to support such a project, but the outcome in terms of both code and
>  >  a student who is familiar with it would not benefit Git very well,
>  >  if at all.
>  >
>  >  --
>  >  Shawn.
>  >
>
>
>
>
>
> --
>  Imran M Yousuf
>  Entrepreneur & Software Engineer
>  Smart IT Engineering
>  Dhaka, Bangladesh
>  Email: imran@smartitengineering.com
>  Mobile: +880-1711402557
>
-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
Noel Grandin· Mar 5, 2008, 14:55 UTC · re: Imran M Yousuf · lore

Re: GSoC 2008 - Mentors Wanted!

Imran M Yousuf wrote:
Show 6 quoted lines
> To start with I was actually thinking of JNI + "exec from C". So later
> when libification is completed we can replace the execs with call to
> the libs directly instead. Is this a viable fourth option (sorry I
> forgot to mention it the first time around)?
>
>

This is probably a good idea. JGIT is always going to be 2 steps behind the native GIT code when comes to accessing on-disk structures.

This is also how the subversion plugin for the Eclipse IDE worked in the beginning and the performance seemed to be acceptable (to me).

Regards, Noel.
Disclaimer: http://www.peralex.com/disclaimer.html
Johannes Schindelin· Mar 5, 2008, 16:37 UTC · re: Noel Grandin · lore

Re: GSoC 2008 - Mentors Wanted!

Hi,
On Wed, 5 Mar 2008, Noel Grandin wrote:
Show 10 quoted lines
> Imran M Yousuf wrote:
> > To start with I was actually thinking of JNI + "exec from C". So later
> > when libification is completed we can replace the execs with call to
> > the libs directly instead. Is this a viable fourth option (sorry I
> > forgot to mention it the first time around)?
> >
> >   
> 
> This is probably a good idea. JGIT is always going to be 2 steps behind
> the native GIT code when comes to accessing on-disk structures.

Well, if you go the JNI route, you will always be platform dependent. IMO this is one of the lesser intelligent things to do when relying on Java.

> This is also how the subversion plugin for the Eclipse IDE worked in the 
> beginning and the performance seemed to be acceptable (to me).

Git is much faster than subversion, so you will feel the overhead of fork()ing, especially on Windows.

Ciao, Dscho

Shawn O. Pearce· Mar 6, 2008, 04:58 UTC · re: Noel Grandin · lore

Re: GSoC 2008 - Mentors Wanted!

Noel Grandin <noel@peralex.com> wrote:
Show 8 quoted lines
> Imran M Yousuf wrote:
> > To start with I was actually thinking of JNI + "exec from C". So later
> > when libification is completed we can replace the execs with call to
> > the libs directly instead. Is this a viable fourth option (sorry I
> > forgot to mention it the first time around)?
> 
> This is probably a good idea. JGIT is always going to be 2 steps behind
> the native GIT code when comes to accessing on-disk structures.
I'm not sure that is really going to be a major issue.

Thus far the Git on disk structure has been very stable over time. We are 3 years old and yet have had very few file format changes, and we are basically still backwards compatible.

The only new major on disk structure that JGit didn't support was
pack index v2, which I just taught JGit to parse tonight.  So yea,
we are a few months behind the bleeding edge on disk format, but
we are caught up again.
 
-- 
Shawn.
Robin Rosenberg· Mar 5, 2008, 21:13 UTC · re: Imran M Yousuf · lore

Re: GSoC 2008 - Mentors Wanted!

Den Wednesday 05 March 2008 08.58.15 skrev Imran M Yousuf:
Show 10 quoted lines
> I would like to suggest 2 projects that I want to work as a developer
> (and/or mentor):
>
> 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
> The aim of the plugin is to integrate GIT with NetBeans using JNI so
> that any change in the implementation of GIT does not effect the SCM
> plugins way of work.
> Language: Java
> Goal: Make GIT available from IDE for NetBeans users and use GIT using
> Java Native Interfaces

As the current acting maintainer or egit/jgit I would not mind cooperating with making it available to Netbeans, J2EE and command line interface or whatever.

You can make a plugin for Netbeans today that will do the basic like walking the history, finding out what to commit, commit, switch/create/reset branches, decorations based on jgit and you wouldn't need to change a thing in jgit. There might be things you *want* to change, but that's another story and applied to the continued development for the Eclipse plugin too. Even the license might be changed.

You will find support in jgit for this today. Cloning over git and ssh real soon. I'm clensing the oopses from the history right now. (bless rebase -i and git-gui).

There are no dependencies on Eclipse and I do not plan on introducing any. Jgit and Egit live in the same repo at the moment simply because there are no other users of egit so far.

There might be some operations that might be harder to do well in Java. For those exec'ing might be the solution, I'm thinking repack, but then I haven't tried it yet. In general jgit is almost as fast as git and probably outperforms git on windows as git there doesn't use memory mapped I/O for packs (something I'd expect someone or even me to fix soon). For JNI'ed operations the complexity is just horrible and even when possible, there is a lot of overhead for JNI itselt, conversion from UTF-16 to somehing eightbitish and back. On windows there's even yet another layer of eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory mapped I/O on all platforms that support it for pack reading.

If someone *did* make a fully reentrant libgit, I'd be inclined to balance my opinions differently.

-- robin
Shawn O. Pearce· Mar 6, 2008, 05:08 UTC · re: Robin Rosenberg · lore

Re: GSoC 2008 - Mentors Wanted!

Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> 
> You will find support in jgit for this today. Cloning over git and ssh real 
> soon. I'm clensing the oopses from the history right now. (bless rebase -i
> and git-gui).
I'm sort of waiting to see this fetch history soon.  :-)

The reason is I just got index v2 support (runtime read side) completed and I want to add index v2 generation to IndexPack. I also want to start building a PackWriter so we can work on native transport push over SSH.

If we get fetch/push running I think we are heading into the area
where it is of some real use to people.
 
> There might be some operations that might be harder to do well in Java. For 
> those exec'ing might be the solution, I'm thinking repack, but then I haven't 
> tried it yet.

I'm determined to even get "proper" packfile generation in Java. But it may be time consuming to build. There may be license issues around doing a direct cribbed port of the delta generation. :-\

Show 11 quoted lines
> In general jgit is almost as fast as git and probably 
> outperforms git on windows as git there doesn't use  memory mapped I/O for 
> packs (something I'd expect someone or even me to fix soon). For JNI'ed 
> operations the complexity is just horrible and even when possible, there is
> a lot of overhead for JNI itselt, conversion from UTF-16 to somehing 
> eightbitish and back. On windows there's even yet another layer of 
> eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory
> mapped I/O on all platforms that support it for pack reading.
> 
> If someone *did* make a fully reentrant libgit, I'd be inclined to balance my
> opinions differently.

Really? If jgit is basically as fast as C git, but doesn't have the overheads of dropping in and out of JNI or fork/exec then you can actually get pretty good performance out of a Java application.

I've never really liked doing JNI. I try to avoid it whenever I possibly can. JVMs just don't seem to be all that happy about loading other native code into them, but yet they can do some very good optimizations when everything is 100% pure Java and the JIT has free reign to do what it pleases.

-- 
Shawn.
Imran M Yousuf· Mar 6, 2008, 05:19 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

On Thu, Mar 6, 2008 at 11:08 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 15 quoted lines
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
>  >
>  > You will find support in jgit for this today. Cloning over git and ssh real
>  > soon. I'm clensing the oopses from the history right now. (bless rebase -i
>  > and git-gui).
>
>  I'm sort of waiting to see this fetch history soon.  :-)
>
>  The reason is I just got index v2 support (runtime read side) completed
>  and I want to add index v2 generation to IndexPack.  I also want to start
>  building a PackWriter so we can work on native transport push over SSH.
>
>  If we get fetch/push running I think we are heading into the area
>  where it is of some real use to people.
>
It is great to hear this news :).
Show 31 quoted lines
>
>  > There might be some operations that might be harder to do well in Java. For
>  > those exec'ing might be the solution, I'm thinking repack, but then I haven't
>  > tried it yet.
>
>  I'm determined to even get "proper" packfile generation in Java.
>  But it may be time consuming to build.  There may be license issues
>  around doing a direct cribbed port of the delta generation.  :-\
>
>
>  > In general jgit is almost as fast as git and probably
>  > outperforms git on windows as git there doesn't use  memory mapped I/O for
>  > packs (something I'd expect someone or even me to fix soon). For JNI'ed
>  > operations the complexity is just horrible and even when possible, there is
>  > a lot of overhead for JNI itselt, conversion from UTF-16 to somehing
>  > eightbitish and back. On windows there's even yet another layer of
>  > eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory
>  > mapped I/O on all platforms that support it for pack reading.
>  >
>  > If someone *did* make a fully reentrant libgit, I'd be inclined to balance my
>  > opinions differently.
>
>  Really?  If jgit is basically as fast as C git, but doesn't have
>  the overheads of dropping in and out of JNI or fork/exec then you
>  can actually get pretty good performance out of a Java application.
>
>  I've never really liked doing JNI.  I try to avoid it whenever
>  I possibly can.  JVMs just don't seem to be all that happy about
>  loading other native code into them, but yet they can do some very
>  good optimizations when everything is 100% pure Java and the JIT
>  has free reign to do what it pleases.

I personally too avoid JNI whenever possible; the only reason I was even thinking of JNI in the first place is just to keep in touch with the latest developments of jGit. But seeing the enthusiasm of the community to contribute in developing a 100% Pure Java Git, I will also participate in development of jGit; I think if we can get it to do the regular operations we can generate enough interest to get a community to regular keep it in sync with git.

>
>  --
>  Shawn.
>
-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
Johannes Schindelin· Mar 6, 2008, 11:04 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

Hi,
On Thu, 6 Mar 2008, Shawn O. Pearce wrote:
> I'm determined to even get "proper" packfile generation in Java.
That's nice!
> But it may be time consuming to build.  There may be license issues 
> around doing a direct cribbed port of the delta generation.  :-\
I am sure a little mail to Nico will give you that license.

Ciao, Dscho

Robin Rosenberg· Mar 6, 2008, 20:48 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

Den Thursday 06 March 2008 06.08.46 skrev Shawn O. Pearce:
Show 21 quoted lines
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > You will find support in jgit for this today. Cloning over git and ssh
> > real soon. I'm clensing the oopses from the history right now. (bless
> > rebase -i and git-gui).
>
> I'm sort of waiting to see this fetch history soon.  :-)
>
> The reason is I just got index v2 support (runtime read side) completed
> and I want to add index v2 generation to IndexPack.  I also want to start
> building a PackWriter so we can work on native transport push over SSH.
>
> If we get fetch/push running I think we are heading into the area
> where it is of some real use to people.
>
> > There might be some operations that might be harder to do well in Java.
> > For those exec'ing might be the solution, I'm thinking repack, but then I
> > haven't tried it yet.
>
> I'm determined to even get "proper" packfile generation in Java.
> But it may be time consuming to build.  There may be license issues
> around doing a direct cribbed port of the delta generation.  :-\

If you know where to look, you might find a version of it. :) I don't think I've changed so much as to prevent you from starting to code the push part.

Show 6 quoted lines
> > If someone *did* make a fully reentrant libgit, I'd be inclined to
> > balance my opinions differently.
>
> Really?  If jgit is basically as fast as C git, but doesn't have
> the overheads of dropping in and out of JNI or fork/exec then you
> can actually get pretty good performance out of a Java application.
I meant "might be".  :]
-- robin
Imran M Yousuf· Mar 6, 2008, 05:33 UTC · re: Robin Rosenberg · lore

Re: GSoC 2008 - Mentors Wanted!

On Thu, Mar 6, 2008 at 3:13 AM, Robin Rosenberg <robin.rosenberg@dewire.com> wrote:

Show 16 quoted lines
> Den Wednesday 05 March 2008 08.58.15 skrev Imran M Yousuf:
>
> > I would like to suggest 2 projects that I want to work as a developer
>  > (and/or mentor):
>  >
>  > 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans)
>  > The aim of the plugin is to integrate GIT with NetBeans using JNI so
>  > that any change in the implementation of GIT does not effect the SCM
>  > plugins way of work.
>  > Language: Java
>  > Goal: Make GIT available from IDE for NetBeans users and use GIT using
>  > Java Native Interfaces
>
>  As the current acting maintainer or egit/jgit I would not mind cooperating
>  with making it available to Netbeans, J2EE and command line interface or
>  whatever.
I am honoured and would be grateful for your support.
Show 7 quoted lines
>
>  You can make a plugin for Netbeans today that will do the basic like walking
>  the history, finding out what to commit, commit, switch/create/reset
>  branches, decorations based on jgit and you wouldn't need to change a thing
>  in jgit. There might be things you *want* to change, but that's another story
>  and applied to the continued development for the Eclipse plugin too. Even
>  the license might be changed.

I was taking a look at the Mercurial VCS Plugin for NetBeans and I think GIT's one will be similar. Using jGit would be great; Do you have any plans to have a Maven version of jGit so that it could be used from any Maven project? Another question is - Is jGit dependent on any Eclipse API (dont even bother if the answer is no)? Can we have a separate repo for jGit so that it is maintained independently on eGit?

Show 25 quoted lines
>
>  You will find support in jgit for this today. Cloning over git and ssh real
>  soon. I'm clensing the oopses from the history right now. (bless rebase -i
>  and git-gui).
>
>  There are no dependencies on Eclipse and I do not plan on introducing any.
>  Jgit and Egit live in the same repo at the moment simply because there are
>  no other users of egit so far.
>
>  There might be some operations that might be harder to do well in Java. For
>  those exec'ing might be the solution, I'm thinking repack, but then I haven't
>  tried it yet. In general jgit is almost as fast as git and probably
>  outperforms git on windows as git there doesn't use  memory mapped I/O for
>  packs (something I'd expect someone or even me to fix soon). For JNI'ed
>  operations the complexity is just horrible and even when possible, there is
>  a lot of overhead for JNI itselt, conversion from UTF-16 to somehing
>  eightbitish and back. On windows there's even yet another layer of
>  eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory
>  mapped I/O on all platforms that support it for pack reading.
>
>  If someone *did* make a fully reentrant libgit, I'd be inclined to balance my
>  opinions differently.
>
>  -- robin
>
-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
Robin Rosenberg· Mar 6, 2008, 20:47 UTC · re: Imran M Yousuf · lore

Re: GSoC 2008 - Mentors Wanted!

Den Thursday 06 March 2008 06.33.26 skrev Imran M Yousuf:
> I am honoured and would be grateful for your support.
Great!.
Show 11 quoted lines
> >  You can make a plugin for Netbeans today that will do the basic like
> > walking the history, finding out what to commit, commit,
> > switch/create/reset branches, decorations based on jgit and you wouldn't
> > need to change a thing in jgit. There might be things you *want* to
> > change, but that's another story and applied to the continued development
> > for the Eclipse plugin too. Even the license might be changed.
>
> I was taking a look at the Mercurial VCS Plugin for NetBeans and I
> think GIT's one will be similar. Using jGit would be great; Do you
> have any plans to have a Maven version of jGit so that it could be
> used from any Maven project? Another question is - Is jGit dependent

Same thing as with Netbeans. We don't need a special version of jgit for Maven, Ant, Cruisecontrol, whatever. We might (will) discover new use cases where we want to put more code into jgit because it not application specific. So go ahead, invoke jgit, send patches etc.

-- robin
Christian Couder· Mar 6, 2008, 05:06 UTC · re: Shawn O. Pearce · lore

Re: GSoC 2008 - Mentors Wanted!

Le mardi 4 mars 2008, Shawn O. Pearce a écrit :
Show 8 quoted lines
> OK, enough, onto the project list!
>
>   http://git.or.cz/gitwiki/SoC2008Ideas
>
> That is only a starting list of possible projects.  At present Dscho
> and myself are listed as possible mentors for a vast majority of
> these projects.  I'd love to get some more members of the community
> involved this year.

I can be a co-mentor if needed, though there are currently no project on the wiki about parts of the code I know quite well (bisect, help, config, refs, GIT_TRACE). If someone has ideas in these areas that would be great.

I also can't be involved in projects on Windows or MacOS, as I use only Linux at home. But otherwise I am willing to co-mentor any other project.

Thanks, Christian.

Christian Couder· Mar 6, 2008, 05:31 UTC · re: Christian Couder · lore

Re: GSoC 2008 - Mentors Wanted!

Le jeudi 6 mars 2008, Christian Couder a écrit :
Show 14 quoted lines
> Le mardi 4 mars 2008, Shawn O. Pearce a écrit :
> > OK, enough, onto the project list!
> >
> >   http://git.or.cz/gitwiki/SoC2008Ideas
> >
> > That is only a starting list of possible projects.  At present Dscho
> > and myself are listed as possible mentors for a vast majority of
> > these projects.  I'd love to get some more members of the community
> > involved this year.
>
> I can be a co-mentor if needed, though there are currently no project on
> the wiki about parts of the code I know quite well (bisect, help, config,
> refs, GIT_TRACE). If someone has ideas in these areas that would be
> great.

By the way, perhaps we could send some "Call for Git GSoC ideas" messages on the kernel mailing list and other mailing lists of projects using Git, to ask them to send us on git@vger.kernel.org some ideas.

Regards, Christian.

Shawn O. Pearce· Mar 6, 2008, 06:44 UTC · re: Christian Couder · lore

Re: GSoC 2008 - Mentors Wanted!

Christian Couder <chriscool@tuxfamily.org> wrote:
Show 19 quoted lines
> Le jeudi 6 mars 2008, Christian Couder a écrit :
> > Le mardi 4 mars 2008, Shawn O. Pearce a écrit :
> > > OK, enough, onto the project list!
> > >
> > >   http://git.or.cz/gitwiki/SoC2008Ideas
> > >
> > > That is only a starting list of possible projects.  At present Dscho
> > > and myself are listed as possible mentors for a vast majority of
> > > these projects.  I'd love to get some more members of the community
> > > involved this year.
> >
> > I can be a co-mentor if needed, though there are currently no project on
> > the wiki about parts of the code I know quite well (bisect, help, config,
> > refs, GIT_TRACE). If someone has ideas in these areas that would be
> > great.
> 
> By the way, perhaps we could send some "Call for Git GSoC ideas" messages on 
> the kernel mailing list and other mailing lists of projects using Git, to 
> ask them to send us on git@vger.kernel.org some ideas.
That's a pretty good idea.

Unfortunately I don't run in those circles. But I guess I can throw a message at a few of our user mailing lists as our GSoC org admin and see if they have anything.

-- 
Shawn.

← back to recent threads