6.17.2011 Weekly Report

Updates inserted  6/20/2011

– – – – – – – – – – – – – – – – – – – – – – – –

This week, I primarily focused on accumulating community feedback on my request page makeover suggestions, and refining the features accordingly.

So based on the limited but helpful user feedback I received, I’ve made the following changes:

1. Remove the count of new requests in the Requests tab from the main view page, and show the new count on the next page.


Update: the UI looks fine now. It should load a bit faster initially, as it can be shown without waiting for the API to respond. 

2. Remove “Add Request” (and possibly place it on a package page), and organize My Requests page based on request status: New, Accepted, Declined, In Review (see the second screenshot above). The “New” tab will show a count of how many “new” requests the user has received. Tapping on this “New” tab will slide over to show the requests.

Update: this is more feasible, as adding a request is needed only in certain context, e.g., the user wants to become the maintainer of a package/project. An “Add Request” button should be added to that project / package view page.  Behind the scenes, this will create an ‘add_role’ request, which will then show up in the requests tab. The same goes for new submit requests — they make sense only if you’re looking at a package. 

I have a few questions here:

Question 1:

Does any piece of code in the webui already filter the request status? How should I go about handling it in the mobile client?

The API provides quite a few options for filtering. The best documentation at this moment is the OBS code, though. Check out the following: 

  • src/api/app/controller/request_controller.rb 
  • src/webui/app/models/request.rb 
  • src/webui/app/models/request_controller.rb 

I was thinking we might not need to have this filtered results pre-compiled or stored anywhere on the server, but instead do this on the fly.

For example, when a user taps “Accepted” requests, it sends a query to the database in the server at run time and instantly returns a list of accepted requests.

I’m not sure which way would place a heavier burden on the server, though, and some insights here would help a lot. I guess it depends on the size of the data being retrieved from the server, the size / memory of the database, the data-processing speed of the database, and the demands of other jobs being processed by the server at the same time.

Due to historic reasons, requests are not stored in a traditional DBMS, but rather as a indexed file storage in the backend (the evil Perl parts). The performance is mediocre, but currently the result list is big, so just try ‘accepted’ requests for openSUSE:Factory:-)

There’s already a plan to add pagination to such queries (i.e. return only the last 20 submit requests for $FOO). 

Question 2:

How do we define “new” requests?

1). New requests since the user’s last login;

2). Requests that require the user’s actions but haven’t been processed by the user.

Which one would work more effectively? Factors to take into account: user’s convenience / preference, ease of filtering requests, data load on the server, etc.

From the OBS perspective, ‘new’ is the initial / default state of every request, regardless of the type. However, depending on the target, most requests automatically enter the ‘review’ state. openSUSE:Factory, for example, has several automatic request checkers. You could do something similar to what the webui does now — it provides a ‘My work’ view with requests which you have to review and new  requests against projects/packages where you have rights for (i.e. are  maintainer/bugowner/…). Next to that, the webui has a generic view which  allows filtering on all requests that somehow relate to you (requests you filed wouldn’t show up as your work, but they belong to you). 

Question 3:

I have the “New” button linked to a list of new requests in /src/webui/app/mobile_views/request/new.html.erb, but the code isn’t functioning well. Sometimes, I get only the text “No open requests” showing up on the page without displaying any request, even though new requests do exist.

Here’s what my new.html.erb file looks like:

/src/webui/app/mobile_views/request> cat new.html.erb 

<% if @requests.blank? %>
 <p><em>No open requests.</em></p>
<% else %>

<div data-role="listview" data-inset="true" data-theme="a">
 <li data-role="list-divider">New Requests Since Last Login</li>
 <% @requests.each do |req| -%>
 <% ae = req.submit if req.has_element? :submit
 ae = req.action if req.has_element? :action %>

 #<%= link_to( req.value( :id ), :controller => :request, :action => :show, :id => req.value(:id) ) -%> to

 <% if ae.has_element?(:target) %>
 <%= elide(ae.target.project, 20) %>
 <% if ae.target.has_attribute?(:package) %>
 / <%= elide(ae.target.package, 12) %>
 <% end %>
 <% end %>

 <br/>from <%= elide(req.state.who, 12) %>, <i><%= fuzzy_time_string( req.state.value "when" ) %></i>
 <% end %> 
 <% end %> 

And in /src/webui/app/mobile_views/home/list_requests.html.erb:

<%= link_to "New (#{@nr_involved_requests})", {:controller => "request", :action => :new}, 'data-transition' => "slide", 'data-icon' => "grid", 'data-role' => "button" %>

I couldn’t really tell what went wrong, as I’m still learning the relationships among the components.


3. Add “Build Status” tab to the request detail page, if the request is related to a package.

Adding ‘buildstatus’ makes sense.

Question 1:

How should I go about filtering requests that are related to packages and have build results?

Shouldn’t filter based on build result status? Most requests would most likely be declined when the build failed, which is usually something you would want to look at. 

Question 2:

How should I filter requests that need the user’s actions, e.g., accept, addrole. I think it makes sense to display these action buttons on the request page only if the request requires user’s actions.

Question 3:

What’s the best way to structure the code that performs these actions? Do we already have related webpages in mobile views?  For example, if a user “accepts” a request, what happens next? Which controllers and actions are required? …

Also, shall I post to the mailing list again to discuss these details again? I’ve waited for a week and got only one person responded… It’s been a bit frustrating.

How should we go about refining and finalizing the features, and eventually implementing them?

I hope to have these questions resolved in the next few weeks.

  • – – – –