Bugspad and Future Plans

Code cleaning, and rigourous testing and bug fixing, underwent this week. Tested the instance with bigger datasets, and the tested for response times.
The current code, is also a bit untidy, and needs some refactoring. So, I have started my work on making, a design documentation, with explicit, details,
of the workflow of the application. Currently hand-drafting it, then I would be digitising it(For the time being I am uploading my workflow explanation,
charts which is not of great quality 😛 ). I have divided the whole workflow, according to urls, and then subdiving it into components, which have an
effect on the performance (especially speed), directly, ie all SQL/Cache queries, being made. This would allow a clear idea, of the purpose, and role
of each component. This would also invite more contributors, and increase the understandability of the current code. Also, it would allow to focus especially,
on the bottlenecks of time in the workflow, and experiment, with different available tools and methods. So, this would be what I would doing into next week. Cheerio!




Xtreme Programming into Bugspad

I am now into the last phase of my project. Due to delays and bit less communication post mid term, due to
my poor internet connectivity (which was my sole responsibility, and I agree 😦 ), I could not discuss much with
my mentor much. However I am planning to use my backup plan to discuss what was remaining, and make the implemented features robust and error free. It will be my toughest week of the project, testing out and removing tad bits of the code. Here I go to have a taste of XP (Xtreme Programming).
PS. Was short on words!

Up from slumber into the pre alpha release mode.

A really long gap of a week, the slumber period, caused by the havocous TPSW department of our college, due to which I could not work much. Now fortunately the period is over. I could not devote much time to my work, so I am going to make up for the time in the coming days. The work planned remains:

  • Redisifying the mysql queries.
  • Fixing any incumbent bugs
  • Working with my mentor on rpm packaging of the code.

The extra features, for the admin interface such as the permissions and groups is due, after this, which we will be working on. In spirit of the pre Alpha release.

Testing, testing and more testing

The previous week, was very eventful. I and my mentor were discussing on the plans of implementing, the groups and permissions feature, which I had planned earlier. However, we concluded that it would be better to clean up the current code, and perform more rigorous testing so that the current implemented features are robust and performance centric. So, have placed the permissions stuff on the shelf for the time being. So far I have been testing via the API, filed 1.7 million bugs or so, only to realise that I wont be able to access those, as I had missed the product versions in each, which I have made compulsory as a part of design decision. So I fixed that part, and am refiling more bugs. The testing which I have done so far, have the result as follows, when only 1 user makes a request at a time:

  • Fetching 10,000+ bugs takes around 1-2 seconds.
  • Filing a bug via API takes around 2-3 seconds(on an average).
  • Filing bugs via the UI(mechanize) takes 4-5 seconds (on an average)

I know the above numbers are not impressive, and the reason behind the same, is that I used mysql at places wherein I should have used redis. So I am onto that now, and more testing, which would be followed by the initial RPM packaging of the application. 😀

Groups, permissions and bugspad.

This week was not much productive in terms of the amount of code written, as I was traveling by the grace of Indian railways. I finally am in my hostel room. However I used this time to plan out things and also test out the bugspad instance on the server. I made a script using mechanize and requests libraries of python to do so, which I’ll be adding to the scripts section of the repo. I am also working on the permissions stuff on a new branch. Instead of having groups I am planning to have usertypes instead keeping it product centric. This would require a minor change in the schema as I would be using charfields to denote the user types. For example, “c1” for users assigned to group with component id 1, similarly “p1” for users with product id 1. Would discuss more with the upstream is my mentor on the missing features and how to go about it.

bugspad missing features

This week composed of reading on missing features of bugspad and planning as to incorporate it. I went through the design docs of bugzilla,whatever was available :P.

  • Group permissions and what to choose for the alpha state of bugspad.
  • Flags to be used for both bugs and attachments.
  • Mailing server setup and handling of mails for the cc list. I and mentor have decided and he is going to help on this to get going.
  • Testing on bigger data sets on the infra system.

I missed the infra meeting last Thursday due to my stupid Internet woes which is finally going to end as I return back to my college. 😀

Bugspad bootstrapped!

Had a refreshing retreat with my family, this week. As planned I was going through bootstrap CSS, to give a decent and responsive look to the UI of bugspad. Also I have been planning on how to use flags in bugspad, alongwith the user group permissions. The following are some of the snapshots of the current revamped after integrating bootstrap. You can otherwise check it out here . I have also been planning to have a mascot for bugspad, as tux is for linux, and the Buggie is for Bugzilla.