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