Re: [anjuta-devel] Anjuta and GSoC2013

[Varad Gautam <varadgautam gmail com>]

I think I should add the following to the Implementation part. Can I
give the reference to the NetBeans issue tracker [1] in my
application?
---
The User Interface consists of windows in the following order:

1. A login window which asks for credentials and the bugzilla link.
This then cofigures the git-bz subcommand.

2. A window with options to

* Browse/Search through existing issues: Selecting this option pops up
another window which asks for various criteria to search upon,
performs the search and displays the search results. The users can
then select a bug from the results and submit patches, add comments to
the bug or even use the submitted patchfiles onto their code.

* File a Bug: This will show another window which lets users file a new bug.
The bugzilla plugin is compatible with the existing git plugin and the
users shall be able to commit from it.

I am using the NetBeans issue tracker plugin [1] as a model for the
bugzilla plugin. They allow svn as well, but I think I should start
with having only git for this SoC.

The project involves extensive use of git-bz subcommand to interact
with Bugzilla

[1] https://netbeans.org/kb/docs/ide/kenai-issuetracking.html

---


On Tue, Apr 23, 2013 at 1:06 PM, Varad Gautam <varadgautam gmail com> wrote:
> On Tue, Apr 23, 2013 at 5:44 AM, James Liggett <jrliggett cox net> wrote:
>
> > Looks like a great start. Just a few comments:
> Thanks for taking the time to review the application.
>
>
> > This has to be at least somewhat figured out before you submit your
> > proposal. When I was a GSoC student I noticed that the admins seemed to
> > care about this part the most. It doesn't have to be set in stone; in
> > fact you should leave yourself a lot of room for parts of the project
> > that run longer than expected, because I guarantee you there will be at
> > least one milestone that will slip. It happens, especially when you're
> > working with an unfamiliar codebase and technologies. It's also
> > perfectly OK if you don't get to everything during the summer. But we
> > would like to have something that's somewhat useful and can be easily
> > understood and possibly maintained by other developers should you not be
> > able to continue the project past the end of the summer. Plus, we're
> > going to need some type of benchmark for midterm and final evaluations.
> I get it. But I'm having problems figuring out the timeline because of
> my lack of experience. I'll work it out as soon as I'm sure of what
> all features I plan to deliver with some consultation from the
> community.
>
> > Your background seems pretty varied and interesting. Would it be
> > possible for you to list the names of or at least some links or other
> > references to these projects? It would be helpful if we could have a
> > look at some of your work so that we can evaluate your experience
> > firsthand. Think of us as a potential employer--we want to see evidence
> > that you can actually code, work as part of a team, and learn new skills
> > on the job. ;)
> I worked on an informal project in college this year aimed at building
> a home automation system which uses Julius as its speech recognition
> backend and OpenCV for object detection. The work hasn't been
> documented anywhere as of now as it's still a work in progress. I have
> a few videos of the project in action which I can put up on the
> internet, but I don't think that would count as documentation...
>
> > On a related subject: in past years GNOME has required GSoC applicants
> > to work on a bug in our Bugzilla. Have you found one to work on yet?
> Yes, I have worked on a patch for bgo#698036
> (https://bugzilla.gnome.org/show_bug.cgi?id=698036), but it requires
> some more attention which I haven't been able to provide because of my
> studies.
>
> Thanks.
> Varad