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?
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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Upstream bugs vs. Fedora bugs: KDE people do it wrong
