Proposal for GSoC, want to get your opinions

On 26.02.08 00:47:57, Evgeniy Ivanov wrote:
> Hi!
> I have an idea to implement git support. Has this
proposal a chance to be
> applied? I have some another ideas, but I like this
much more than others.
> I will be glad to get any answers.

In general I think that is a good idea, even if only to
check that our
distributed vcs interfaces are properly designed. Given the
rise of git
as distributed vcs and that there are few if any good
graphical clients
out there I think this proposal has a good chance of getting
approved.

Andreas

-- 
What happened last night can happen again.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 25 February 2008 23:03:33 Andreas Pakulat wrote:
> On 26.02.08 00:47:57, Evgeniy Ivanov wrote:
> > Hi!
> > I have an idea to implement git support. Has this
proposal a chance to be
> > applied? I have some another ideas, but I like
this much more than
> > others. I will be glad to get any answers.
>
> In general I think that is a good idea, even if only to
check that our
> distributed vcs interfaces are properly designed. Given
the rise of git
> as distributed vcs and that there are few if any good
graphical clients
> out there I think this proposal has a good chance of
getting approved.
>
> Andreas

I'd love to see git support in kdevelop-4, git is a great
version-control 
system, especially for small local projects. Maybe it would
be best if such a 
system could leverage already existing good solutions like
QGit(it has a nice 
revision-graph). I also think this project has a good chance
of being 
accepted.

Greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday, 25. February 2008, Evgeniy Ivanov wrote:
> Hi!
> I have an idea to implement git support. Has this
proposal a chance to be
> applied? I have some another ideas, but I like this
much more than others.
> I will be glad to get any answers.

Will this task be enough to warrant 2-3 months of work?

During the recent GHOP, two students wrote backends for my
Version Control API 
(server-side, PHP, for Git and Mercurial) in about one week
each. Given, 
those were pretty smart guys, and they didn't have to
implement many 
functions of the respective version control system, but with
a bit of effort 
you can get a basic interface running in virtually no time.

There's already a working interface in KDevPlatform, and two
"example" version 
control backends (CVS and Subversion) that can be used as
templates, so 
there's probably not much work left than the actual
interfacing code.

I propose to start ambitious and include all three major
DVCS (Git, Mercurial, 
Bazaar) in the task description for an eventual GSoC
proposal.

The nice thing with version control backends is even if the
student backs off 
somewhere in the middle, the resulting code can still be
reused with little 
effort, and if there's more backends with, say, one not
being finished then 
the other ones still work as well.

So:
1. Finish basic functionality for a working Git backend.
2. Finish basic functionality for a working Mercurial
backend.
3. Finish basic functionality for a working Bazaar backend.
4. Stuff that I can't think of because I didn't follow the
evolution
   of the VCS interfaces and where stuff is still lacking.

That would make a rather nice GSoC project, I believe.

Cheers,
  Jakob (not available for this year's Summer of Code as a
student)

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 26 February 2008 01:19:51 Jakob Petsovits wrote:
> Will this task be enough to warrant 2-3 months of
work?
Imho that depends on what you want to do...

> So:
> 1. Finish basic functionality for a working Git
backend.
> 2. Finish basic functionality for a working Mercurial
backend.
> 3. Finish basic functionality for a working Bazaar
backend.
> 4. Stuff that I can't think of because I didn't follow
the evolution
>    of the VCS interfaces and where stuff is still
lacking.

I can think of the alternative approach. The student can
strive for 
completeness and maturity instead of basic functionality.
Emacs, for example, 
can be the source of inspiration when it comes to vcs
integration features.

Also I'd like to see vcs integration plugins extensible
(using qtscript or 
kross). Basically, there should be a way to run user
commands, add them to 
appropriate menus, display results, change code in the
editor and so on.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 26.02.08 00:19:51, Jakob Petsovits wrote:
> On Monday, 25. February 2008, Evgeniy Ivanov wrote:
> > Hi!
> > I have an idea to implement git support. Has this
proposal a chance to be
> > applied? I have some another ideas, but I like
this much more than others.
> > I will be glad to get any answers.
> 
> Will this task be enough to warrant 2-3 months of
work?

Depending on the students pre-knowledge I think yes. Its not
just about
writing a parser for the git output and calling git from
inside
KDevelop. We're going to need some UI as well and that can
get complex
for a DVCS. We don't even have basic stuff like branching
and tagging
for the existing VCS, especially no UI. 

Its also not quite clear wether our existing interfaces are
properly
designed for a DVCS (I sure hope so, but without a backend
its hard to
tell for sure), so there might be design work and discussion
needed as
well...

Last but not least: You can always extend the SoC project if
you see the
student moves along fast. Given my experience last year that
makes more
sense than stuffing a hundred things into the project and at
the end
having to admit that there were only 30% achieved or
something like
that...

Andreas

-- 
While you recently had your problems on the run, they've
regrouped and
are making another attack.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 25.02.08 23:51:20, David Nolden wrote:
> On Monday 25 February 2008 23:03:33 Andreas Pakulat
wrote:
> > On 26.02.08 00:47:57, Evgeniy Ivanov wrote:
> > > Hi!
> > > I have an idea to implement git support. Has
this proposal a chance to be
> > > applied? I have some another ideas, but I
like this much more than
> > > others. I will be glad to get any answers.
> >
> > In general I think that is a good idea, even if
only to check that our
> > distributed vcs interfaces are properly designed.
Given the rise of git
> > as distributed vcs and that there are few if any
good graphical clients
> > out there I think this proposal has a good chance
of getting approved.
> >
> > Andreas
> 
> I'd love to see git support in kdevelop-4, git is a
great version-control 
> system, especially for small local projects. Maybe it
would be best if such a 
> system could leverage already existing good solutions
like QGit(it has a nice 
> revision-graph).

Sounds like a good chance to label KDevelop4 as an app that
utilizes
QGraphicsView 

Andreas

-- 
You will stop at nothing to reach your objective, but only
because your
brakes are defective.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 26 February 2008 07:50:35 Andreas Pakulat wrote:
> Depending on the students pre-knowledge I think yes.
Its not just about
> writing a parser for the git output and calling git
from inside
> KDevelop.

Btw. please do NOT write an own parser if not absolutely
needed, we have 
already have to maintain enough of them in kdevelop-4, and
I've seen it take 
a lot of time. It would be best if the cores of already
available and stable 
applications like qgit and gitk could be re-used.

A problem about git is that the interface will probably
change yet, so being 
code-wise close to those apps would make accomodating to
such changes easy.

Greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 26.02.08 11:05:32, David Nolden wrote:
> On Tuesday 26 February 2008 07:50:35 Andreas Pakulat
wrote:
> > Depending on the students pre-knowledge I think
yes. Its not just about
> > writing a parser for the git output and calling
git from inside
> > KDevelop.
> 
> Btw. please do NOT write an own parser if not
absolutely needed, we have 
> already have to maintain enough of them in kdevelop-4,
and I've seen it take 
> a lot of time.

For a full blown language like Python, sure. But for the
output of some
commandline tool its not that much of a problem, IMHO. At
least as far
as I can see the amount of parsing done in CVS support is
really little
(it even gets away with QRegex).

> It would be best if the cores of already available and
stable 
> applications like qgit and gitk could be re-used.

That essentially means forking them, having to understand
that code...
Depending on the existing knowledge of whoever does this it
might be
faster than to write a parser, or it might slow down even
more...

> A problem about git is that the interface will probably
change yet, so being 
> code-wise close to those apps would make accomodating
to such changes easy.

Interface? Which interface? There is none. I don't think any
of us
seriously considers commandline output an interface.

Using the ouput is a hack, no matter what. However I don't
see us fixing
the underlying architectural problem in git (or feature,
whatever you
want to call it).

Anyway, if we can borrow the parsing code and other parts
from qgit (I
don't see much value doing that with gitk) then yes, it
might help to
start off fast. I'm not so sure about long-term maintenance,
that might
proove to be hard as I suspect we'll going to adapt the
forked sources
or fix bugs ourselves...

So my conclusion is: Wait and see wether the project is
accepted and
what the student thinks gets him further...

Andreas

-- 
Good night to spend with family, but avoid arguments with
your mate's
new lover.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

I agree with everything above (I mean usage of existing
applications/code, features needed...). But as Andreas have
told the
idea is not only in parser writing. I will try to sum up
everything
above:
1.
Finish basic functionality for a working Git backend (git
support,
using current KDevelop API and similar to existing modules).
If needed
some design changes and fixes.
2.
-Making vcs integration plugins extensible (using qtscript
or
kross). Basically, there should be a way to run user
commands, add them to
appropriate menus, display results, change code in the
editor and so on.
-Basic stuff like branching and tagging
for the existing VCS, UI.

>  > Will this task be enough to warrant 2-3 months of
work?
>
>
> Depending on the students pre-knowledge I think yes.
Its not just about

If to be sincere, at this moment I'm a bit far from vcs
(just used
cvs/svn commands to work with code). And my experience in
development
consist of just few projects (sdlgraph for FPC, QOrganizer
fixes and
from December I work with mozilla project - write patches).
Before
starting my GSoC project (if I will applied) I want to make
some
«initial research» to see the current code, another
applications (QGit
for example).
I want to finish things that would be listed in the
proposal, if I
able I will make much more.
Also there is a time after summer  It's a
good time to become KDE
developer (at this time I just contribute some
translations).

-- 
E.I.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel