Interest in doing a sprint? (was: Re: [NCLUG] Speakers for 2007/2008?)

Sean Reifschneider jafo at tummy.com
Wed Sep 19 05:07:27 MDT 2007


On Tue, Sep 18, 2007 at 10:11:32AM -0600, mike cullerton wrote:
>Depending on language and complexity, I'd love to do something like  
>this.

It really depends on the scope of the project.  I've recently been doing a
lot contributing to Python lately, here are some of the things I've done
this last few days:

   Looked at the documentation and suggested alternate wording

   In the bug tracker:

      Reports with no priority assigned, reviewing and prioritizing.

      Verifying that when a user reports a problem that it still occurs on
      the latest trunk build.  Particularly useful for reports that are a
      year or two old.

      Looking at SVN logs and "svn blame" output to see who owns the code
      related to patches on un-assigned reports, and assigning them.

      Looking at old, stagnating reports and asking the participators what
      needs to happen next.  Or suggesting actions for them to take to move
      it forward.

   Digging into the bzip2 module code to track down a subtle problem which
   caused a trailing garbage character to be added at the end of
   decompressing.  Reviewing, rewriting, and simplifying the code in
   question, and resolving the issue.

   Back-porting patches.  A patch to "trunk" may also need to be converted
   to work against an old maintenance release.  In many cases this is just
   verifying that the patch cleanly applies against the old version.

I'm just using python here as an example because it's something that I've
spent a lot of time working on this week.

As you can see, quite a few of these tasks require little if any
programming knowledge.  Many of them aren't even very technical.

In Fedora, there is plenty of help needed with reviewing packages.  There
is a detailed checklist of things you should do (download this file, check
it's checksum against the package, is there a license, does it build, is it
readable).

These are some projects that I'm familiar with and have reasonable
privileges that we could actually make some significant forward progress in
without having to rely on out of the area participation.  I'm sure there
are other projects that are represented around here as well.  Lots of the
HP folks are heavily involved in Debian, but they haven't been making it to
NCLUG much lately.

Any project with a public, preferably active, bug tracker can accept
outside participation.  And if we had enough people, it might even make
sense to have a couple of different sprints going on.  If we did Python we
could probably get folks from Boulder to come in.  We could probably even
get funding from the PSF to provide meals and beverages.

So, now that I've explained what sorts of things a sprint can involve,
what sorts of things are people interested in doing if we were to have
a sprint?

Another option in a similar but slightly different direction is to have an
"unconference", one of the "bar camps".  These can vary quite a bit, but
one format is that everyone at the conference has to talk about something
they are interested in.  Another format is just a bunch of rooms with
sign-up boards, and people sign up for topics they are interested in
talking about, and often it's a round-table discussion of the topic.

Sean
-- 
 When men are pure, laws are useless; when men are corrupt, laws are
 broken.  -- Benjamin Disraeli
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability




More information about the NCLUG mailing list