Hi list,

This is the first email in hopefully a long running series wherein I
try to describe some of the recent developments in the
gitorious/mainline.git repository.

The motivation for starting this is quite simply
information. Currently Gitorious is mainly developed by Marius and
myself as part of our day job, which is lovely and all. But since we
sit in the same room I realise that every outside that room have
little clue what we're doing, or what we might do in the near
future. Hopefully emails like this will help others getting introduced
to Gitorious development, as it's a good excuse to state an
oppinion or jumping into the codebase.

Since this is the first, it's a bit long in terms of the "recent"
timespan as well as textual length, so make sure you got some
tasty beverage handy.

TOC:
-------
- Merge requests & inline commenting
- jQuery & Javascript tests
- Collaborators, not just committers
- ~user profile facelift
- The new "watch" feature
- Clone list searching
- Mailing list spam
- Closing statements

Merge requests & inline commenting
------------------------------------

This one is about a month old or so and I wrote a bit about in the
blog (http://blog.gitorious.org/2009/11/06/awesome-code-review/), but
the interesting thing in terms of code is that the merge requests are
now far more Javascript powered, both for browsing the revisions that
the MR is composed of but also the actual inline commenting.

The inline commenting is one of my favorite new features in recent
times, and personally I think we solved it much smoother than any
existing review-ish software employing similar approaches. The inline
commenting is also available on normal commits. The new merge requests
and inline commenting was also the main motivation behind the next
thing.

jQuery & Javascript tests
-----------------------------

We're now using jQuery for all our javascript (and has for a while),
and we try to do most things "unobtrusively". Not so much in the
providing-no-javascript-enabled fallbacks since I think that's just pointless
in 2009 and beyond. Gitorious requires javascript enabled, anything
else is just not supported. By "unobtrusively" I'm refering more to
the seperation between the javascript and the HTML; don't use the
rails default javascript helpers that just sticks the javascript
directly into the HTML. There's still places where this is done, but
mostly for the smaller things, instead we try to use meaningful
element identifiers and custom attributes for the places where we
can't feed data into the javascript otherwise (ajax urls are a good
example here). Generally the custom attributes are either prefixed
with "data-" or namespaced under the "gts" prefix (eg
gts:url="/foo/bar.js"). Clearly this is a place where consistency
needs to be applied.

More javascript also means more places where things can go wrong, so
we're unit testing some of the bigger javascript modules. For running
the tests we're using the awesome js-test-driver library
(http://code.google.com/p/js-test-driver/).
In a nutshell you start up a small webserver (rake test:start_server),
open up http://localhost:9876/ in a bunch of different browsers. When
the tests are run (with "rake test:javascripts") the test server (a
small java socket server) then sends the testcases to each captured
browser, evaluates it in each browser and then reports the results
back. The test cases are located in test/javascripts/*_test.js and
config/jsTestDriver.conf tells js-test-driver what files to load.

I recommend anyone wanting to do javascript testing to use this
libary, it's just fantastic. My collegue Christian Johansen has
written an `autotest` style gem called jstutil
(http://cjohansen.no/en/javascript/jstdutil_a_ruby_wrapper_over_jstestdriver)
for running the tests as well.


Collaborators, not just committers
-----------------------------------

Previously you where only able to add or remove committers on a
repository. Well, now we're calling it collaborators (I'm open for
other names here) and each collaborator on a project can have
"review", "commit" and "admin" permissions. "commit" and "admin"
should be fairly obvious, the "review" one gives the user permission
to manage merge-requests, useful if you want someone to triage merge
requests, but not give them commit rights to the repository.

The model class is still called Committership, which sucks. The
permissions are implemented as a bitmask
(http://gitorious.org/gitorious/mainline/blobs/master/app/models/committership.rb#line24)
and are stored as a bitwise OR
(http://gitorious.org/gitorious/mainline/blobs/master/app/models/committership.rb#line70).
Nice
and easy. Futhermore the Repository has
committers/reviewers/administrators methods for retriving the users
with those permissions. If one where inclined to add a read permission
(for private/hidden repositories), this new Committership model would
be the place to start.

~user profile facelift
-----------------------

Your user profile page has gotten a slight facelight (here's mine:
http://gitorious.org/~johan), making it slightly more dashboardy if
you're viewing your own profile. The reason is to make room for the
next item:

The new "watch" feature
------------------------

Previously is was a bit tidious to keep up to date on projects on
gitorious you where somehow interested in. Either you'd have to add
each project to your feedreader or just remember to visit them
reguarly. That sucks. Futhermore whenever there was certain kind of events
on your repository you'd get an email (new merge-requests for
instance). This was less than optimal in case you had committers on a
repo that just didn't care about merge requests.
So as step towards better notification features you can now watch
different objects, such as repositories and specific merge requests,
events from these then appear in your personal newsfeed on your ~user
page. Users can also unwatch an object at any time. When you create
something you're automatically watching that (so you'll get updates
about your own merge requests for instance)

The watch feature is implemented via the Favorite class, it's a simple
join model between a user and a polymorphic object (such as a
Repository, MergeRequest). There's a favorite_button() helper that
takes any object (its class must include the Watchable module though)
and renders a button to watch/unwatch that object.
The actual newsfeed is based on the FeedItem class. Whenever an event
is saved there's an after_create callback that creates FeedItems for
all the watchers of an object
(http://gitorious.org/gitorious/mainline/blobs/master/app/models/event.rb#line128).
The
FeedItem object contains a User and an Event id. The reason for this
is mainly performance; It's must faster to simply look up a list of
Event ids and then fetching those events, than doing a join between
the rather large events table and the favorites.

The feature is still cooking, but I think we'll be able to deploy it
on gitorious.org in the beginning of next week.


Clone list searching
---------------------

For repositories with lots of clones (such as
http://qt.gitorious.org/qt) the repository clone list in the sidebar
was just getting unbearable, both for finding a specific clone but
also it made the page too heavy and slow to load. So there's not a
quicksearch thing showing if there's more than five clones.

The javascript implementation of the searching is a really good
example on how to test javascript via js-test-driver, see
http://gitorious.org/gitorious/mainline/blobs/master/test/javascripts/repository_search_test.js


Mailing list spam
------------------

As a sort of final administrivia, the mailing list is just letting
tons of spam in recently. We can all thank Google for this. Thank you
Google for not being able to fix this after weeks of spamming lots of groups.

I'm not too keen on running our own mailinglist just yet (as we'll end up with
lots of spam anyway since I probably don't have time to setup enough
antispam filters). I hope everyone has sufficient spam filtering to
not be overly annoyed by this.


Closing statements
-------------------

Do let me know what you think emails of this type, was it useful and
informative? Too abstract?  I hope to do them on a weekly or montly
basis from now on.

Regards,
Johan

--

You received this message because you are subscribed to the Google Groups 
"Gitorious" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/gitorious?hl=en.


Reply via email to