Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Juha Tuomala]

On Wed, 31 Mar 2010, Jeff Spaleta wrote:
> No. I'm asking for you to clarify that you feel clone is appropriate
> for wide spread use for the specific situation I'm commenting on.  We
> are very much stuck in a trap of designing our workflow to fit the
> tools we have, instead of designing our tools to fit the workflow we
> want.

True. If I put myself into enduser's position, she will certainly
only look for the release she has, doesn't find the report among 
50-100 other report and certainly is not going to start looking for 
other releases. Then she gets slapped into face with DUPLICATE and 
her valuable well crafted comments get lost when maintainer didn't 
bother to copy those comments / nyancies into 'right entry'.

I've seen this happen many times. And not being an enduser, I don't 
like it either.

Those are just numbers and some db/disk space, that's all.

> I fully recognize that and I'm sincerely asking if you think as
> a matter of policy everyone should be encouraged to clone to as a way
> to avoid using fixed rawhide as a closure when updates aren't going to
> come down for a specific release.

If that remains broken in f11, I'd like to see it cloned there. It 
will show up in queries and prevents duplicates to happen. It saves 
people's time. There are more people wasting time entering those 
duplicates than maintainer saves with current workflow.

It wouldn't get people upset at the front door, those people we 
would like to step ahead and participate. Behaving badly towards 
them through a machine is not going to make them feel that this is a 
community I'd like to join to. Nor report anything again.

> I'm asking for a sketch of a policy that would do better at accurately
> portraying what deficiencies are alive while still allowing
> maintainers to efficiently track which issues they've resolved to
> their satisfaction.

> Till's message about the difficulties inherent in cloning bug 
> comments are on point.

Yes, he has a point. Imo if the matter is complex and requires a lot 
of comments, that could happen in rawhide entry, other release 
entries could just work as status tracking and have a comment that - 
real, release neutral discussion takes place in 'main bug'. Those 
could even depend on it.

> Cloning seem very cumbersome as a general policy.

Yet it happens quite a bit when RHEL is involved.

> But we can certainly find a way to discuss making it less 
> cumbersome without getting hot under the collar.

And that's assumption, towards a person. Why not just let the 
matters argue?

>> Sometimes I get a feeling, that Fedora is not even meant for 'normal'
>> people, not now, not in the future. Currently it certainly is not.
>
> There's a lot of emotion in those sentences which I'm not really sure
> I can do anything constructive with.

Where you do you see emotion there? :D That's a fact.

I suggest that if you disagree, make your own field experiments with 
people. I've done mine and they failed. Last one was an economist - 
a friend of mine - that got fed up with Windows he had. He brought 
the whole topic up/idea himself. After some time of trying, he's 
still using windows.

> We can always try to do better. And I think generally speaking 
> that is what people here want to do...to try to be better. But a 
> lot of the time emotive speech derails the intent.

or getting it derailed by turning the discussion to metadiscussion.

http://fedoraproject.org/wiki/User_base
> Fedora contributors understand that they may not be representative 
> of a very large class of users who may find free software serves 
> their needs as well. By setting the bounds of this larger class, 
> we can make good decisions about how to make Fedora work well for 
> as many people as possible, including ourselves
>
> The Board considers these aspects applicable to the work of the 
> entire Fedora Project. The Board will encourage process changes 
> where appropriate to ensure we are meeting the needs of as many 
> members of this class as possible.

http://fedoraproject.org/wiki/User_base_-_general_productivity_user
> They are common to both novice and experts alike

I think that says quite clearly that we should think those processes 
from enduser's point of view. We know here what the current workflow 
is, what rawhide, those resolutions, etc stands for. Enduser 
doesn't since those are not obvious/clear whatever.

and btw, last time i suggested to get rid of that 'rawhide' because 
it overlaps with 'devel' and is non-obvious, idea got shot down 
'beacuse it fun inside joke'. I guess the bug is in target user 
definition then. :)


Tuju

-- 
I couldn't repair your brakes, so I made your horn louder.