[fab] Fw: [Bug 174307] RPM 4.4.6 is available

Stephen John Smoogen smooge at gmail.com
Mon Jul 10 14:12:11 UTC 2006


On 7/9/06, seth vidal <skvidal at linux.duke.edu> wrote:
> On Sun, 2006-07-09 at 20:46 -0600, Stephen John Smoogen wrote:
> > I can tell from longer history, that this has come up in 'lessons
> > learned' since at least 1998.. and keeps coming up. It has always been
> > "next time we will communicate better" but something always comes up
> > and there is always a good list of reasons why communication broke
> > down again (lack of people, extra demands on engineers, etc.). At this
> > point, I would have to say the problem needs serious management power
> > aimed at it with it being put as a priority. A developer can only deal
> > with so many issues (features, bugs, packages, upstream communication,
> > downstream communication) and the company has to manage that number or
> > it will end up with burnt out developers, poor community relations,
> > and tanking sales.
> >
>
> I have a problem with this statement.
>
> This issue was brought to the board on friday. We've had all of 2 days
> to discuss and I'd like for there to be a board meeting before we make a
> final statement.
>

Sorry, I am trying to show a systematic problem with communication
that needs to be looked at by the board. It is a problem that has been
brought up internally multiple times at RH when I was there.. and your
answer is pretty much the stock one: "We just got this problem, and
have had 2 days to fix it... "

I am talking about a general problem with communication. The bug was
opened in November of 2005. There was no communication until it was
closed from Red Hat other than marking a bug duplicate. I have a
couple of bugs in the same condition from RHL 8.0.  [The problem may
be that there isnt a significant organization memory to

> It's hard to communicate an answer to a problem when we didn't really
> know there was one. Its one package out of what? 3000? And it's one bug
> out of 150K?
>

I do not know how many bugs it is currently. When I did a close-a-thon
of bugs during the end of RHL, the number was in the hundreds of open
bugs in the NEW condition that had no developer interaction. Currently
while there are over 5000 NEW bugs in bugzilla I would say about 2000
of them look over 6 months old.

> How do you think this should have been handled?
>

Well, my point of view is from a service background so my view towards
customer interaction/satisfaction is where I come from. Bug reports
are as much a public face of Fedora/RH as the website. A customer
should get some sort of interaction from an official person within 7
working days. This can just be a triage of:

Thanks for the report, it looks to be a duplicate of XYZ so I am
combining it in this report.

Will have to work with the upstream maintainer on getting this  fixed.
It may take a while to get a proper fix though so this bug may go into
hiatus for a while.

This looks to be a feature request that would have to be in a future
release. Will put on as a 'blocker' for project management to look at.

Thanks for the report, currently engineering is having to concentrate
on work in <fill in sections here>, and are needing to keep RPM in a
conservative mode. We are backporting changes from upstream RPM that
does not overly change the behavior of RPM-4.2. We are looking to
focus on a major change to RPM in a future release.

> A problem has been happening in a bug in bugzilla
>
> The maintainer didn't know what the best answer was so he brought it to
> the board
>
> We've been discussing it and will come up with something shortly.
>
> why is this not communicating? How did we fail to communicate?
>

Ok the issue for me is trying to say that communication delays/failure
have been a long term problem. Each time a new organization management
comes in and says they will deal with it but seem to focus on the
particular crisis versus the entire problem. Then a new group comes in
and we repeat, lather, rinse. I should have phrased my earlier email
differently, but what I am trying to do is act as a memory unit:

Bugs take a long time to get interaction, people get pissed, community
problems surface, and 'management' reacts. In this case, management
realizes this has occured in the past, and can 'act' in a way to study
and cure the larger problem versus one aimed at specifically at RPM.

Does that clear up what I am trying to say?


-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator




More information about the fedora-advisory-board mailing list