Fedora Women Day 2016

CnZe3pLUAAAwGrm (1)

Fedora Women Day is celebrated to raise awareness and bring Fedora women contributors together. This is a great time to network with other women in Fedora and talk about their contributions and work in Fedora Project.

The event was held at Netaji Subhash Engineering College (NSEC) in Kolkata, India on 15th July, 2016.

Fedora Women Day was also celebrated in Pune, India and Tirana, Albania. https://fedoraproject.org/wiki/Fedora_Women_Day_2016#Local_Events

The event started at 10:30 AM. Women started coming in and it was pretty nice crowd.

The event started with my talk. It was my first talk so I was really excited.

I talked about Fedora Women Day and the purpose. Then I started talking about the work I do in Fedora Project. Most of the part of my talk was regarding Fedora Infrastructure and Fedora Cloud.

Since my most of the contributions lie in Bodhi(Fedora Infrastructure) and Tunirtests(Fedora Cloud) so I specifically gave some insight on these projects. I explained the architecture of Bodhi and Tunirtests and how one can start contributing those specific projects.

I also shared my story on how I started contributing to Fedora Project.

Here is the slide of my talk: trishnaguha.github.io/trishnagslides-what-i-do-in-fedora-how-can-you-get-involved.html

After few hours of my talk I had to leave early for some urgent work. You will find the full event report here: Event Report.

I received Fedora stickers, F24 workstation DVD and Fedora T-shirt, but not sure I can put the T-shirt on, it seems so large :(.

Jpeg

Advertisements

A Moment to Cherish

It was June when I was interviewed by opensource.com for my Opensource (FOSS) journey and Summer training in Dgplug.

https://opensource.com/life/16/6/how-community-taught-me-code

Heartfelt Thanks to my family, mentors and friends I have come across so far!

Definitely a moment that I would love to cherish for lifelong :).

Contributions:  https://github.com/trishnaguha  https://pagure.io/user/trishnag

First Guest Session of DGPLUG Summer Training 2016

Screenshot from 2016-07-06 14-06-08

I never imagined that Kushal Das (Mentor of DGPLUG) would ask me to take the first guest session at DGPLUG summer training 2016. I was one of the participants of DGPLUG summer training 2015.

Few days ago I was asked to take the first guest session at DGPLUG summer training 2016 about my journey in FOSS, Python and DGPLUG. I became super excited after hearing that and also it was the first guest session of DGPLUG summer training 2016. It was really unexpected :). The next day I took the session at 18:30 IST on #dgplug channel on IRC.

I started with little introduction about me and let the participants ask Questions after that. The whole session went really interactive. They asked smart questions despite being newbies :).

The mostly asked Questions were How I started my first upstream contribution, How did I select the project I worked on for the first time, What do I do when I am stuck at an issue, How do I manage time to contribute along with my studies, How FOSS helps in career, Steps to contribute in a better way and all.

I really enjoyed answering all kind of Questions those were asked.

You can join the summer training still now. Join #dgplug channel on IRC and the Mailing list. Fill up the form and ping Kushal Das. Feel free to ask if you have any query on IRC or Mailing list. You get this golden opportunity only once a year, so don’t miss it.

The IRC logs are uploaded here. You will find all the conversations here https://dgplug.org/irclogs/2016/Logs-2016-07-01-15-00-trishna.txt.

It feels amazing to be a part of such a great community :).

You Would Never Know Where The Bug Is

Screenshot from 2016-07-05 13-21-26

If you can’t reproduce the bug you would never know where the bug is!

I realized exactly the same when I have been working on a bug of Bodhi. We were pretty clueless about why the bug has arrived. After working on it for long I now believe that I am able to figure out where the bug is, Though the work is still going on. But we are pretty closer to it now. The current state is https://github.com/fedora-infra/bodhi/issues/855.

If we were not be able to reproduce to the bug we would never know why the bug had arrived and believe me it was not really identifiable this time! So before working on patch for a bug we should always try to reproduce it first.

Why Reproduce Bugs?

If you can’t reproduce the bug you would never know where the bug is. Patch doesn’t work just on guess. You are expected to be failed to create a patch if you fail to reproduce the bug.

If you don’t go through the steps when the bug is arrived it is technically impossible to create a patch. After you know why the bug has arrived it is possible for you to fix it as well. If you can’t reproduce the bug you need to create a patch just guessing the issue and you are not sure whether it is going to work or not! So it is not considered as a good practice.  Make sure you are not wasting your time on creating patch about which you are not sure.

Good Bug Reporting: Generally a good bug report contains all required info like when the bug has arrived, what was expected to happen and what has actually happened.

There are bugs about what we have no idea why they have occurred neither the users nor the developers. But the developers can always figure it out by reproducing the bug i.e, creating the same situation(In non-technical word). We will now see How Can We Reproduce Bugs.

How To Reproduce Bugs?

Unittest!

Unittest is one of the certain ways in order to reproduce bugs. I will show a simple demo.

We will write a simple program to check whether a number is odd or even.

Write the code:

Screenshot from 2016-07-05 20-57-56

Write the test:

Screenshot from 2016-07-05 20-58-08

Test is supposed to fail since 6 is an even number. Now we will see what happens:

Screenshot from 2016-07-05 20-54-52

Now we know why the error has occurred. In order to reproduce bugs we always want our test to fail.

This is just the fundamental of unitesting on reproducing bugs. You will know more when working on real world projects.

We can use Pdb also. Check this to see how you can use it.

For Bodhi I have used unittest and mock testing. Here is the testcase I wrote to reproduce the bug I mentioned above: https://paste.fedoraproject.org/386958.