Emacs and the Google Summer of Code

Emacs and the Google Summer of Code

[Nick Roberts]

I'm pleased to say that "Emacs GDB/MI migration" was accepted as a Google
Summer of Code student project throuh the GNU Project.  So I would like to
welcome Dmitry Dzhus to this list as the student of that project.  I will be
acting as his mentor but I am sure that he will be able to get support from
everyone here too.

As I stated in January, I would like the resulting code would replace gdb-ui.el
after the release of Emacs 23.1.  Is there any estimate for the release date?
It would be best to commit changes to the repository, so if the release is
expected to be after the coding start date of the project (May 23) then it
would be helpful to cut a new branch where new features for Emacs could go.  I
know that RMS does not like this idea, as he thinks that all focus will shift
to the new branch, but I'm not sure if that's true and there are drawbacks
in not having one.  Debian seem to manage with both a testing and unstable
distribution.

If that's not possible, changes will have to go to Tom Tromey's Emacs Lisp
Archive, where the existing mode (gdb-mi.el, modified gud.el) resides, but the
feedback from there, so far, has been nil.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


GNU Project's accepted proposals:
http://socghop.appspot.com/org/home/google/gsoc2009/karlberry

Student Project Emacs GDB/MI migration:
http://socghop.appspot.com/student_project/show/google/gsoc2009/karlberry/t124022551883

Timeline:
http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline

Emacs Lisp Archive
http://tromey.com/elpa/

Re: Emacs and the Google Summer of Code

[Miles Bader]

nickrob@snap.net.nz (Nick Roberts) writes:
> I'm pleased to say that "Emacs GDB/MI migration" was accepted as a Google
> Summer of Code student project throuh the GNU Project.

yay!

-miles

-- 
Arrest, v. Formally to detain one accused of unusualness.

Re: Emacs and the Google Summer of Code

[Chong Yidong]

nickrob@snap.net.nz (Nick Roberts) writes:

> As I stated in January, I would like the resulting code would replace
> gdb-ui.el after the release of Emacs 23.1.  Is there any estimate for
> the release date?  It would be best to commit changes to the
> repository, so if the release is expected to be after the coding start
> date of the project (May 23) then it would be helpful to cut a new
> branch where new features for Emacs could go.

The code seems to be converging to a good state, and the manual checking
is about 90% complete.  So I think we should be able to branch before
the end of May.

I plan to roll a new pretest on April 30.  I think, and Stefan has
agreed, that we'll introduce a regressions-only policy once this new
pretest is out: no fixes to bugs that already existed in Emacs 22.

I'll send another reminder email as we get closer to that pretest.

Re: Emacs and the Google Summer of Code

[Stefan Monnier]

> I'm pleased to say that "Emacs GDB/MI migration" was accepted as a Google
> Summer of Code student project throuh the GNU Project.  So I would like to
> welcome Dmitry Dzhus to this list as the student of that project.  I will be
> acting as his mentor but I am sure that he will be able to get support from
> everyone here too.

Great, congratulations!

> As I stated in January, I would like the resulting code would replace
> gdb-ui.el after the release of Emacs 23.1.  Is there any estimate for
> the release date?

It doesn't matter.

> It would be best to commit changes to the repository, so if the
> release is expected to be after the coding start date of the project
> (May 23) then it would be helpful to cut a new branch where new
> features for Emacs could go.

Put it in a branch.  If it can be put into the "branch for Emacs-23.2",
that might be OK, but it can just as well go into another branch.
Another good option is to put it into a Bzr or Git branch.

> I know that RMS does not like this idea, as he thinks that all focus
> will shift to the new branch, but I'm not sure if that's true and
> there are drawbacks in not having one.  Debian seem to manage with
> both a testing and unstable distribution.

This is a completely different issue.  We're talking about a branch for
a particular feature.  We're not talking about opening "a new trunk".


        Stefan

Re: Emacs and the Google Summer of Code

[Nick Roberts]

 > > I know that RMS does not like this idea, as he thinks that all focus
 > > will shift to the new branch, but I'm not sure if that's true and
 > > there are drawbacks in not having one.  Debian seem to manage with
 > > both a testing and unstable distribution.
 > 
 > This is a completely different issue.  We're talking about a branch for
 > a particular feature.  We're not talking about opening "a new trunk".

I probably wasn't very clear but that's exactly what I was talking about.
Yidong's post also seems to suggest that this might be possible.  Creating
a sparate branch for one Emacs mode is probably not worthwhile as experience
from GDB tells me that very few people would check that branch out.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs and the Google Summer of Code

[Stefan Monnier]

>> > I know that RMS does not like this idea, as he thinks that all focus
>> > will shift to the new branch, but I'm not sure if that's true and
>> > there are drawbacks in not having one.  Debian seem to manage with
>> > both a testing and unstable distribution.
>> This is a completely different issue.  We're talking about a branch for
>> a particular feature.  We're not talking about opening "a new trunk".
> I probably wasn't very clear but that's exactly what I was talking about.
> Yidong's post also seems to suggest that this might be possible.  Creating
> a sparate branch for one Emacs mode is probably not worthwhile as experience
> from GDB tells me that very few people would check that branch out.

As long as we're in pretest, I don't really want to encourage people to
try development code.  But AFAIK, there's still a fair bit of
development to be done on that GDB/MI thing before it needs testing, so
I think it's not an issue.


        Stefan