Re: [anjuta-devel] Anjuta and GSoC2013

[Varad Gautam <varadgautam gmail com>]

Here's my entire proposal. Please take a look into it. I have added
the features suggested by Johannes. Do you think the timeline I have
created is okay? Also, the application format requires possible
mentor's name for the project.
Thanks.
---

Bugzilla Integration for Anjuta DevStudio IDE



 * What is your e-mail address and IRC nick?

e-mail address: varadgautam gmail com

IRC nick (on irc.gnome.org): varad



 * Do you have a web page, blog, or microblog?

Blog URL: varadgautam.wordpress.org



 * What is your academic background?

I am in my first year at Birla Institute of Technology and Science,
Pilani (India) studying Electronics and Instrumentation Engineering.



 * Who is a possible mentor for the project you are proposing?

---###---



 * What is the ultimate goal of your proposal?

Anjuta DevStudio is a fast and lightweight IDE with support for C,
C++, Java, JavaScript, Python and Vala. It is greatly suited for open
source software development on GNOME.

Each open source software project maintains a track of its current
bugs into some form of issue tracking system like Bugzilla, which
makes it convenient for contributors to collaborate on code from
across the world and keep a track of pending issues with the software.

I propose to build an extension for Anjuta IDE which integrates it
with Bugzilla so that the programmers using the IDE can:

-View bugs posted on the Bugzilla page of the project they’re working on,

-File new bugs,

-Upload patches

-Close bugs,

-Receive patches for an existing bug and apply them, and,

-Comment on pre-existing bugs

I will create a plugin for Anjuta which provides a user interface to
interact with Bugzilla. The interface consists of the following
windows

1.            A login window which asks for user credentials and the
URL of the bugzilla page, which pops up once to authenticate the user,

2.            Another window with options to

                i.              Browse/Search through existing issues:
Selecting this option pops up another window which asks for various
criteria for search (such as Issue ID, keywords, component etc.),
performs the search and displays the   results. The users can then
view the bug along with all the associated parameters like Severity,
Priority, Assigned to. Selecting a bug lets them submit patches, add
comments or apply patches to their own code.

When a commit is being made from the existing git plugin, the commit
message is parsed for tags like “Closes: bgo#xxxxx” and the user is
prompted if the bug should be closed.

ii.         File a Bug: This will show another window which lets users
file a new bug. Users

can select the component, version, severity and other properties
associated with their bug and file it along with a description.



* What components/modules will the proposed work modify or create?

My proposal requires writing a bugzilla plugin and modification of the
existing git plugin for Anjuta IDE.



 * What benefits does your proposed work have for GNOME and its community?

The project will benefit all those who use Anjuta IDE regularly for
development. Users will no longer have to manually visit Bugzilla
pages and submit patches. Instead, they can do the same with ease from
within the IDE itself.

The feature is also a part of Anjuta’s Project Roadmap, and will be a
useful addition to the IDE.



 * Why are you the right person to work on this project?

About my experience in programming:

I can program in C/C++, Python and Java. I have built GUI applications
using Swing and PyQt. I have also programmed for the BeagleBoard and
have fair know-how of shell scripting.

I can easily get used the code written by others and start working on it.

Me and the idea:

I think building a bugzilla integration feature for Anjuta is a much
needed task and would really ease the process of bugfixing. It can
save a lot of time for the developers, and will be a great step ahead
for the IDE. I am keen to work on it.

I started quite early and have been discussing the idea with Anjuta
developers for a while and have gained a lot of useful insight about
how it can be implemented.



 * How do you plan to achieve completion of your project?

I will work on the following aspects for the completion of my project:

-Read the documentation and get used to Bugzilla WebService interface,
which will act as the core of my plugin

-Build the user interfaces in GTK+ for each of the mentioned windows one by one

-And add the corresponding functionality to each user interface using
the Bugzilla WebService interface.

-Integrate the plugin with Anjuta

-Testing and documentation

My timeline is as follows:

Before the program starts, i.e. till June 17: Lay the groundwork by
interacting with the community, figure out the problems that might
arise and get well acquainted with the APIs I plan to use.

Week 1: June 17-23- Start with building the user interfaces required

Week 2: June 24-30- Finish up with the UI, start programming the login
window to authenticate and connect with the corresponding bugzilla
website.

Week 3: July 1-7- Have the login screen ready. Pick up the search-bug
feature and start integrating it with the Bugzilla WebService API.

Week 4: July 8-14- Complete the search feature. Test, debug and
formally document the work done so far.

Week 5: July 15-21- Start implementing the comment and upload patch feature.

Week 6: July 22-28- Complete the leftovers; also add the ability to
apply patches.

Week 7: July 29-August 4- Submit the work Mid Term Evaluation. Work on
the review received.

Week 8 & 9: August 5-18- Work on the feature to file a bug.

Week 10: August 19-25- Contingency week; See if everything works fine;
If not, fix it.

Week 11: August 26-September 1- Test and document.

Week 12 & 13: September 2-16- Make changes to the existing git plugin
to make it parse the commit message and allow closing bugs.

Week 14: September 17-23- Wrap up. Clean the code and finally test it. Document.

For Mid Term Evaluations, I will have built a plugin which lets users
search and browse the bugs



* What are your past experiences with the open source world as a user
and as a contributor?

I have been using GNOME for over seven years now, and am quite a fan
of its simplicity and ease of use. Only recently have I come across
open source software development, and find it very interesting. I
would like to become an active part of the community and contribute to
it.



  * Please include a link to the bug you fixed for the GNOME module
your proposal is related to.

https://bugzilla.gnome.org/show_bug.cgi?id=698036

Some work still needs to be done, haven’t been able to finish it
because of studies.

  * If available, please include links to any other code you wrote for
GNOME or other open source projects.

None.



 * What other relevant projects have you worked on previously and what
knowledge you gained from working on them?

I have worked on a home automation project this year in college that
involved using a BeagleBoard to build a voice-controlled
position-based lighting system using Julius Speech Recognition Engine
and OpenCV as the backend.  I have gained a considerable knowledge of
cross compiling and developing for the ARM processor. I have also
learnt how to program a microcontroller and interface it with a
BeagleBoard wirelessly using Zigbee.



* Will you have any other time commitments, such as school work,
another job, planned vacation, etc., between June 17 and September 23?

My college reopens in July, and I might have to lose a week or two for
its registration process and some other formalities. Other than that,
I have no commitments.


On Wed, Apr 24, 2013 at 2:13 AM, Varad Gautam <varadgautam gmail com> wrote:
> 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