Older blog entries for badger (starting at number 75)

On 07/21/2009 04:24 AM, Dimitris Glezos wrote:
> For me, Fedora isn't so much what we think it is -- it's
> what our community wants it to be. And if a part of our community
> wants to try new things out, given that the resources needed won't be
> unmanageable, we should encourage them to do so.
> 
Posted on the Fedora Advisory Board list

I think that this is very, very true and something that we need to keep in mind as go about defining what Fedora is. Thanks Dimitris, for phrasing that so succinctly!

FISL in the Morning

The Fedora booth has been well populated by Fedora Ambassadors from all around Latin America from Brazil to Mexico. For someone from the insular world of the United States, it's awe-inspiring to watch the ambassadors in action. Even though some speak Spanish and others Portuguese, they cheerfully work out their differences in language and laughingly toss jokes at one another. A line of potential Fedora users stretches out from the booth, entertained to watch interviews of Fedora ambassadors and developers as they wait to sign up for a FAS account and get the Brazilian Fedora 11 spin.

The conference is huge. And very oriented on free software. I attended LinuxWorld in San Francisco once and the crowd was roughly this size. The type of attendee is very different, though. Where LinuxWorld seemed to have an abundance of businessmen looking to buy or sell a solution to someone else, FISL seems populated mostly with enthusiasts eager to meet up with fellow contributors to the projects they are involved in. A very nice crowd to watch and try to interact with despite my limited Portuguese.

Luis hits the nail on the head.

People who lean toward the DAG as *recording* history will prefer Mercurial or Bazaar. People who tend to see the DAG as a tool for *presenting* changes will prefer git.People who lean toward the DAG as *recording* history will prefer Mercurial or Bazaar. People who tend to see the DAG as a tool for *presenting* changes will prefer git.

-- Stephen J. Turnbull on python-dev

While this doesn't express my main issues with git (which are UI driven) (although the UI might be irretrievably broken because of these features... I dunno :-), it does capture the reason I don't jump up and down when contemplating git's "advanced features".

Found out today that git, bless its heart, has non-symmetric UI. watch:

[badger@Clingman bugzilla]$ git pull
Already up-to-date.
[badger@Clingman bugzilla]$ git push
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 418 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/python-bugzilla
   c387d20..ef6bb9c  master -> master
 ! [rejected]        0.5 -> 0.5 (non-fast forward)
error: failed to push some refs to
'ssh://git.fedorahosted.org/git/python-bugzilla'

After a bunch of head scratching we finally realized that pull only updates a single branch whereas push attempts to update them all. Horrible UI. Imagine the case where you're sharing dozens of feature branches with other developers. Before you push new work you have to git pull in each of them?

And a Warm Thank-You To...

Ignacio Vazquez-Abrams (ivazquez) is one of the most helpful people around. He seems to always be present on #fedora-python answering questions. He gives out sound packaging advice on fedora-devel-list. Many contributors fondly remember him helping them through package reviews or making sure they were on the right track after he sponsored them.

My current thank-you is for the task he took on for the new release of python-fedora. A TurboGears identity provider that allows our web applications to have single-signon with the Fedora Account System has been a feature of python-fedora since the first release. ivazquez has added an auth provider that does the same for Django applications. This was a frustrating task as he had to work with the guts of python-fedora's client module, understand the TurboGears authentication scheme, the Fedora Account System API, and then map all of that into the Django authentication provider.

Thanks to his work we'll have authentication against the Account System when we deploy the Django version of Transifex (And a thank-you is owed to the Transifex devs for the shiny new release!) just in time for the Fedora-11 string freeze.

I've been looking for this quote all day and like magic, it appeared in someone's email sig.

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.

Albert Einstein 1879 - 1955

Now, apply that to git.

Greg Dekoenigsberg pointed this out to a few of us and it's worth repeating to a wider audience:

Except where otherwise noted, third-party content on this site is licensed under a Creative Commons Attribution 3.0 License. Visitors to this website agree to grant a non-exclusive, irrevocable, royalty-free license to the rest of the world for their submissions to Whitehouse.gov under the Creative Commons Attribution 3.0 License.

-- http://www.whitehouse.gov/copyright/

Mass branching was a success! For Fedora 9, mass branching of packages took 2 days to complete. For Fedora 10 it took 2 hours.

The savings is thanks to Bill Nottingham who cut out some unnecessary steps to the cvs branching script and to Jesse Keating and myself who implemented some more efficient code for the Package Database portion.

JavaScript

JavaScript is a mass of failures. But it's also a fun language. Why the contradiction? I get the impression that it just isn't a very complete language in a lot of ways. Here's my short, top-of-the-morning list of JavaScript shortcomings:

1. No way to specify dependencies between modules.
2. Lack of a comprehensive standard library.
3. No standard method of taking well organized code (for instance, separate files) and turning them into something that is efficient for the network.
4. Using prototype for inheritance has a few corner cases that you have to have knowledge of in order to avoid pitfalls (this could just be me, though).

Most of the major JavaScript frameworks out there have some code in them to address these failings. This is both a plus and a minus. On the one hand, it means that it is possible for JavaScript to be extended to work around these problems. On the other hand, it means that instead of learning JavaScript, a serious programmer has to learn jQuery or Dojo or Prototype. And it means that when you find that you really love one feature about one framework and a second feature about another framework you either have to make the user download both frameworks (with all the duplication in functionality between them) or suffer through a suboptimal means of doing some things since you are restricted to just one.

And now that I've got the rant out of my system, let me tell you what I like about Dojo and jQuery and why I wish JavaScript made it easy to use both together:

jQuery

• jQuery has a very rich querying method for selecting JavaScript nodes that extends the standard CSS selectors in useful ways.
• jQuery has an equally rich series of methods that operate on the queried nodes. Even though Dojo has a query() method that can do similar work as jQuery, the richness of methods that can apply is somewhat restricted in comparison.
• In other words, jQuery has an area of specialty: selecting nodes from the DOM and manipulating them. It's the best framework I've encountered for doing that

Dojo

• Asynchronous programming in Dojo is easy with the twisted-style Deferred. Programming network requests and other long running or recurring events asynchronously is natural with Dojo.
• Specify dependencies from within JavaScript files. You don't have to use html script tags to specify all the JavaScript files to load or where to load them from; the dependencies mechanism does that for you.
• Build system to take your organized code and make it suitable for deployment. Lots of little files become one JavaScript file so the browser doesn't have to make multiple requests or even an option to allow asynchronous loading.
• dojo.declare() makes object oriented javascript much easier. It's fun working with prototype and the nitty gritty of JavaScript's prototype-based OO because it's different than the class-based inheritance that I'm used to but I also get extremely tired of debugging problems with prototype inheritance because there's just one little thing that I don't understand (and seemingly, no one else on the internet does either :-) or writing boilerplate over and over.
• In other words, where jQuery makes it easy to do all things DOM related, Dojo makes it easier to develop and deploy the rest of your application.