> Doesn't work. English being the ridiculous language it is, 'any' in
> fact
> has precisely the same problem as 'or'. It can mean 'any one of
> (these
> things)' as well as 'all of (these things)'. You can read 'any
> release
> blocking package set' as 'any one release blocking package set'. In
> fact, we use 'any' in this sense *right there in the same criterion*
> -
> for Beta, we say 'any officially recommended upgrade mechanism',
> meaning
> any _one_ officially recommended upgrade mechanism (only one has to
> work). English, you can't beat it.
>
> We can't use 'all', either, like we do for the mechanisms for Final,
> because it could be read as 'you have to be able to do an upgrade
> from a
> system with both KDE and GNOME installed'.
>
> I _think_ - think, mind - that 'each' would work:
>
> "It must be possible to successfully complete an upgrade from a fully
> updated installation of the previous stable Fedora release with each
> release-blocking package set ('minimal', and the package sets for all
> release-blocking desktop environments), using any officially
> recommended
> upgrade mechanism. The upgraded system must meet all release
> criteria."
>
> and the corresponding thing for Final, obviously.
>
> Actually, god, no, that doesn't work either, it has the same problem
> as
> 'all'. This is freaking hard. Quick, somebody call a university.
>
> I think we have to rejig the whole thing somehow. Um.
>
> For each one of the release-blocking package sets ('minimal', and the
> package sets for each one of the release-blocking desktops), it must
> be
> possible to successfully complete an upgrade from a fully updated
> installation of the previous stable Fedora release with that package
> set
> installed, using any officially recommended upgrade mechanism. The
> upgraded system must meet all release criteria."
>
> I _think_ that gets it (with, again, the obvious corresponding
> criterion
> for Final). English, eh. Who'd use it.
That almost begs for a mathematical formula instead.
Now seriously - after reading the email, I wonder whether non-native English speakers will ever be able to distinguish these subtleties. I wanted to say "especially for those outside the QA team, who don't read this list often", but then I realized that I'll forget the correct meaning soon myself, and I'll have to ask for confirmation again and again in the future.
If we want to engage more community and link to these criteria, so that they tag blocker bugs, they have to be as accessible as possible. Maybe we could put explanations right into the criteria text? Like "any of supported mechanism (all of them must work)" or "any of supported mechanism (at least one must work)". It doesn't look pretty and it makes the text longer, but it makes it pretty clear.
Of course if we intend to use these criteria only in the core QA team, and ask community to tag blocker bugs intuitively (without really reading those criteria), then it's probably fine. But one day, one day, we will be deciding blocker bug status and no English language expert will be around, and then it's gonna be tough.
I'd rather have it longer and clearer.
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
