[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