Gerrit Build Finally Successful

As the title already gave away, the latest patch we submitted on gerrit has finally built successfully

Capture 3

The patch page itself is here

Now we just have to wait and hear what they say about our code, which is probably going to be another mountainous challenge to deal with, but that’s what we signed up for after all …



Table Turning Time

It has been the fifth time that we have re-forked our repository as new and re-submitted the patch. As I write, I am cloning a fresh fork for the 5th time.

The problem is that patch submitting from a new repository seems to be pretty easy. But once that patch fails (for simple reasons sometimes), editing the code and re-submitting the patch becomes a pain because git begins messing up with previous commits. Yesterday even strange duplicate codes were showing up in my local file. So the only choice is to delete my fork and create a new fresh one, apply changes and submit the patch. There is definitely an easier way, but git is not making it easier for us.

One good thing that happened is that now we can actually see the log for the Jenkins build, which tells us why something fails.

If the fifth fork fails and we have to do this all over again, … it’s table turning time.

Patch Submitted … Again. Build failed … Again

Two days after the first patch was submitted, we received two comments from the reviewers: one saying that our commit title was not good (too long and doesn’t contain bug number). So we needed to resubmit the patch.

But that wasn’t a piece of cake. For some reason, the logerrit review submitting system kept giving errors. problem.png

Googling the error didn’t produce any worthy solution (or I wasn’t able to see the worth in the solutions suggested) and they didn’t respond when we reached out to them. Fortunately, I used another system of submitting using git-review.shot

This time, the patch got submitted again, but the Jenkins building tool still just emailed me back saying that the build failed again. I am currently building the project in my local and see what happens …

Patch Submitted

Finally our efforts are ready to see sunlight!! My fear that I would be work-less all week was reverted and I managed to submit our code patch for review. The process was not easy and LibreOffice’s explanation of how to submit a patch was kind of confusing … or we were confused somehow. As I posted it last time, this are instructions they posted:


First, we misinterpreted the first line to mean that we create a new branch from the terminal, when what we have to do was pick an existing local branch that is already in the github repository. Actually it is not even necessary to find a non-master branch as I submitted the patch from the master branch of my forked, updated repository. Github says that it is always better not to used master for stuff, but I don’t see any eminent danger here.

Second I did not use the “add file” part at all since my branch is already up to date with my local, and we spent most of our time last time trying to add individual files. And the commit has already been done while pushing changes from local to github.

In general, if one is working in a branch that is already in sync with the local where all the changes are committed, all they have to do is the last line (./logerrit …), which will give them a little more pain about Change-IDs. Once, that is solved, the patch will be submitted.

Anyway, I set the person who posted the bug as a reviewer (as he requested) and our code is proudly sitting and waiting for review (as you can see it in the link below)

Our bug was relatively simple, and there is a large possibility that our code was not perfect at all, but I feel great about actually going through most of the process of contributing code to an open source project. What is the next step? Maybe another bug? …

Recent Work and (possible but hopefully not) Hiatus

In short, patch submitting over the weekend + Monday did not work out. We added ourselves as members of the developer list and began the process of submitting the path, following this process


However, after we created a new branch, we are having trouble making it sync with github and add all our file changes using the add command. The errors also include a mismatch of email addresses between gerrit and github (author email address does not match your user account) which doesn’t make sense because Shona had the same email address setup for both systems.

Anyway, that is where we are now, and it is very likely that we will be on hiatus until next Tuesday as my awesome teammate (she made me say it … but I agree) is going to a codeathon in California, and my build is broken 😦 😦 But I will try my best to continue working on it by possibly cloning her already updated code. We shall see …


This week, Shona and I have been mainly working on transferring our solution code from our local only copy, where we have been working on, to a forked copy of the source code connected to github. After pushing the code to github, we worked on connecting our system with gerrit, LibreOffice’s code review system where they review code before submission.

The gerrit setup included some straight-forward command line work as outlined on LibreOffice’s developers page. We are currently in the process of adding ourselves to LO’s developers list (a requirement before one submits a patch in gerrit), a process currently stalled due to email dysfunction during our last meeting yesterday. We are hoping we will submit the patch for review over the weekend.


We. Bug. Fix.

Fstream did save our lives, because we have a strong feeling that we have actually fixed the bug! But first, I need to calm myself down and go over a few problems we encountered before we caught the aforementioned feeling.

After we set up file output, we began testing our new function by inserting pictures of varied sizes to see what the function does to them and how it changes their final dimensions. This led to us finding out that pictures that are bigger than the slide remain untouched (like we want them to) but when pictures smaller than the slide are entered, the system crashes. We stopped our class meeting on Wednesday after this dreadful discovery.

When we met again tonight, therefore, we inserted more outputs (mostly Shona’s not very nice one-liner opinions about me!) to see how far into the function the system goes in before crashing. When we opened the text file after the next crash, Shona’s opinons were ALL over the page. What a nightmare! It turns out that our ‘while’ statement that checks to see if the picture was smaller than the slide was going on forever, and we could have easily used an ‘if’ statement in stead. And we did that. And our function worked as expected.

After the excitement that we might actually have fixed a bug, we also found out that we both love making lists. The night couldn’t have gone any better! So, we made a list of what is left for us to do which looks something like this:

  • Duplicate our solution for the rest of the conditions such as when there are two or more pictures per slide
  • Test appropriately
  • Write documentation about everything we did
  • Make a pull request

And we can’t wait until the crossing-off starts. That’s always the fun part.