Monday, March 14, 2011

In response to "the libappindicator story"

I generally never weigh in on these things, but I think in this case I understand what some may be missing here.

This is in reference to the following blog post: the libappindicator story

Each side refers to process and how the other side failed to follow it. My question is "can anyone point me to the relevant documentation which shows the process being referred to" and "can both parties review this process to see where they fell down" and "can the process be reviewed to ensure that it is clear and works so as to prevent similar future issues".

I suspect that there is no documented process, nor is it generally understood as to how all this was supposed to work by both parties. It's easy to reject an idea citing some failure to comply with a non-documented process. I'd like to be proven wrong and see that a process actually exists and work from there, but I suspect it's currently vapourware.

It's fine for you to state Canonical did not follow the process, but to not link to a doc or provide a post showing the process as approved by either GNOME or the team within GNOME responsible for this particular area, it's quite frankly irresponsible.

In order to make any such claim, you need tangible documentation. GNOME is big enough and the teams are diverse enough, that you need to document process. How else do you get efficient and allow new development to occur? You cannot exist forever in a vacuum.

So, if there is indeed a well documented process, show us the link. Show Mark that his team failed to follow the documented process. Then, once that's done we can move on. Mark will admit defeat and apologize and we can call it a day.

However, if this is not well documented nor consistent across GNOME projects, then GNOME needs to recognize that the lack of a documented process may have contributed here and let's correct that and move on.

PS: I work in a very process driven area (customer service and delivery) and it requires well documented processes to function. I understand all to well when some process exists virtually and is not well documented what can happen. Orders get missed, revenue drops, productivity suffers. As well, people point fingers. The only way to rectify is document the process and get everyone to acknowledge it. The process doesn't have to be perfect, it just has to be documented so you can at least have a reference point to move forward from.

Peace.

7 comments:

  1. Jef Spaleta and Jeff Waugh have both posted similar details and, seemingly, not been heard but now Dave Neary has given the process details to Mark Shuttleworth in exacting detail.

    http://www.markshuttleworth.com/archives/661#comment-347596

    All that is left is for people, on all sides, to actually follow these processes.

    N.B. It has also been stated, on numerous occasions, that to work well with any project you ned to adopt the tools and processes that that project already uses...so GIT not launchpad and publicly archived discussion and debate not clandestine meetings and private email.

    ReplyDelete
  2. Howdy. I wrote that post. There will be another in the series that goes into more detail about the process, and why libappindicator didn't really fit in with... well, anything at all.

    All of the GNOME release process stuff is documented on the GNOME wiki:

    http://live.gnome.org/ReleasePlanning

    ReplyDelete
  3. I wonder what the obsession is with git. It's like a religion, you're not allowed to use anything but git and if you fail to use and follow the git, then you are not worthy.

    Give me a break.

    That's exactly the kind of insular attitude that is a problem in Gnome.

    ReplyDelete
  4. It's not really about git, it's about using GNOME infrastructure.

    When a GNOME developer is given access to the GNOME revision control system (back when it was CVS, SVN or now git), he or she can commit to any GNOME module at all. It fosters collaboration across the entire GNOME stack. If parts of that stack are hosted elsewhere, more work is required to find them, gain access, request a merge or commit directly, etc.

    That's only one example of why using GNOME infrastructure has historically been important, but you raised the revision control system, so I answered in that context. :-)

    ReplyDelete
  5. @Martin: replace 'git' with 'launchpad', and 'Gnome' with 'Canonical' ;)

    ReplyDelete
  6. @Anonymous: Actually Launchpad !~ git, the more accurate would be bzr.

    Launchpad is actually a very AWESOME application, and much of my development would have not been as easy without it.

    ReplyDelete
  7. @Anon,

    Or replace GNOME with kernel and git with git.

    Or replace GNOME with Qt and git with git

    Or replace GNOME with Gstreamer and git with git

    Or replace GNOME with Meego and git with git

    The point is individual projects have their own collaboration culture. If you want to participate inside of of a given project then you will lower the amount of friction by following the established best practices which include coding style and collaborative infrastructure use.

    I look forward to the day when launchpad grows the ability to interact with git as a competitive option with bzr. That would be an interesting realization of Shuttleworth's own interest in seeing technologies "compete" inside the Canonical controlled walled garden that is launchpad.

    -jef

    ReplyDelete