[sldev] Linden's new Sustaining Engineering group
Paul Nolan
nolan-paul at btconnect.com
Thu Sep 4 01:36:33 PDT 2008
Hi,
I'm really interested in this change; and wnat to be a part of it.
with that aim in mind, I have a suggestion I hope you'll entertain.
I assume you are going to be deciding which viewer-bugs-
and-'featurettes' fail within the domain of this group. If so, would
you mark Jira entries in such a way that they become searchable
(keyword, category, etc - whatever will be easiest).
The sort of annotation that would allow a Jira Subscription email
filter that listed the 'Sustaining Engineering issues : unresolved
and available for opensl developers to work on'
Personally, this is the sort of contribution I prefer to make; small
and discrete changes I can work on and deliver in my spare time.
This is the type of patch I've submitted in the past (yes, I know it's
been a while - working for a living, family, old house in need of
'sustaining engineering' 8-) etc ) and is the type of work I'd like
to do more of.
Cheers
Paul
---
RL: Paul Nolan
SL : Paul Churchill
On 4 Sep 2008, at 00:06, Kent Quirk (Q Linden) wrote:
> Hi, everyone.
>
> This message is just a little announcement about a change we've made
> at Linden Lab recently (about a month ago now) -- we've created a
> group of people whose job is explicitly to focus on what's known as
> "Sustaining Engineering" for the viewer. Basically, that's doing the
> maintenance to keep the heat on and the roof from leaking.
>
> I'm the manager of the Sustaining Engineering group, and on the team
> are some people you've seen on this list -- Soft, Tofu, and Coco.
>
> In particular, our charter is:
>
> * Handling viewer bugs. This is defined partly by what it's not --
> namely, it's not architecture, and it's not anything that requires
> significant refactoring or changes the user interface in significant
> ways. But it is annoyances and UI glitches as well as programming
> errors.
>
> * Handling "featurettes". These are the small features that make
> people's lives easier or fix UI inconsistencies. Recent examples
> included moving some menu items, enabling and disabling buttons at
> key times, and the feature that allows dropping inventory directly
> onto an IM window.
>
> * Handling open source patches. Yes! We now have people at LL whose
> job is, explicitly, importing patches and getting them into the
> release. We've been trying, in recent weeks, to be very responsive
> to patches submitted, and explicit about what we're doing with them.
> It doesn't mean we'll take every patch thrown at us, but I hope that
> when we don't take them, we'll be able to give better guidance as to
> why.
>
> What you should see from us in the next few weeks/months:
>
> * An increased attention to patch submissions in the PJIRA. We do a
> weekly internal triage of issues in PJIRA, and our priority is to
> first consider issues with patches, then new issues, and finally to
> revisit issues that have already been considered but need additional
> action or are getting old. As I said above, our goal is to respond
> to all patches rather than letting them languish, even if the
> response is "we can't take this".
>
> * Aggregation of PJIRA issues into related topics. You saw this
> earlier this week with Rob's post on patch bundling for Chat/IM
> messages, but we hope to do a lot more of that, and to enlist this
> community in tackling collections of related issues in a timely
> fashion.
>
> * An improvement with respect to reflecting accurate status in
> PJIRA. A common phrase in our triage now is "will you please update
> the PJIRA?"
>
> * A gradual improvement in patch throughput from submission through
> to release or at least visible builds. This is a general Linden Lab
> issue -- our release process is long right now -- but the Sustaining
> group can help by aggregating issues through release in a timely
> fashion. We can also try to publish branches as early as possible in
> our development process.
>
>
> I'm very excited about this new group. I will continue to show up at
> the weekly open source meetings, at my own office hour, and I will
> try to come to the public triage meetings when I can. I also read
> this list and from time to time log in on the #opensl IRC channel.
> In short, I'm pretty easy to find -- please come talk to me.
>
> Q
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
More information about the SLDev
mailing list