On Fri, Nov 9, 2018 at 10:31 AM Lukas Ruzicka <lruzi...@redhat.com> wrote:
> OK. First of all, it might be confusing that you used the same term "core
>> apps" for something that might be a bit different, even though I see the
>> logic. It's currently used just in Workstation, you mean distro-wide. They
>> are not specific apps, they are "app types".
>>
>
> Yes, exactly.
>
>
>> The Workstation spec has specific requirements for them, you have other
>> requirements in mind. Unlike our current practice, you don't actually
>> require them to be installed, it's just a recommendation for spins.
>>
>
> No, not exactly. I require them to be installed and in the menus of
> graphical DEs, so that whoever chooses any of the suggested DEs (Anaconda
> offers them) should be able to start something with it without being too
> confused.
>
Requiring something without blocking doesn't make sense to me. You either
need to block or kill the spin (neither of which I want to do), or it's not
a requirement, it's a recommendation.
>
>
>> * I don't feel in a position to decide which app types should fall into
>> the category. That would probably be a FESCo decision.
>>
>
> We have never gotten so near, but true - if that has to be a distro-wide
> decisions, this should be a FESCo thing to decide.
>
>
>> * I'm not convinced that every spin needs to include app type X. Some DEs
>> are highly different, like SoaS. If you include Labs in the mix, or
>> whatever is present in comps, there could be (hypothetically) some highly
>> specialized environments, like a tiling manager with cli-only tools, or
>> whatever.
>>
>
> You are right, but except SoaS there is nothing called "working
> environment with DE", so I really do not require we check for everything.
> By the way, a tiling manager IS a graphical DE and if the core applications
> are all solved with CLI-tools ... I do not see any reason why not.
>
>
>> * Your definition seems to only think about graphical desktop
>> environments, which goes against claim that this would be universal for all
>> Fedora.
>>
>
> Yes, that is true. And maybe you have spotted a requirement to have such
> core applications for the Fedora server as well. In that requirement, the
> sender asked for preinstalled and preconfigured services ... and hey ...
> maybe it is not a bad thing at all (definitely a proposal for Server SIG).
> For sure, it is out of scope of our discussion. In a server environment,
> you always end up with CLI tools anyway, so I do not expect users get
> confused by that.
>
>
>>
>> Overall it seems to me that if we just reported e.g. "hey, you seem to be
>> missing a text editor in the main menu" to LXDE, it would solve the same
>> problem without bureaucracy and definitions.
>>
>>
> This is what my proposal is really about, Kamil. It seems to me that
> currently we do not file many bugs for non-blocking environments, we just
> let them go with the flow. Why? Because there isn't any required test case
> to test for them. Sure, we do not have time and resources to do it
> thoroughly, but we could at least test for "core applications" in those
> environments.
>
I can't say I'm fond of a mandatory test case for non-blocking stuff. I'm
often bad at choosing my fights, but testing non-blocking spins is
definitely not my fight, and I'll rather spend my time on something else
that is more important (read blocking) and/or currently on fire (there are
always things on fire). That doesn't mean I don't report bugs for
non-blocking apps and sometimes environments, I quite often do when I hit
them during my day-to-day usage, but that's very different from a mandatory
test case for that. Fedora provides a big playground for many different
software projects, they can built stuff on top of Fedora, and it's up to
their fanbase to make sure things are working. This is a perfect place for
community to help out, if they regularly use these environments.
If this is an optional test case to help community focus on a few selected
most important parts, i.e. guiding them where to best devote their time,
sure (and we can think whether a test case is the best means to achieve
that). Guiding people is always good and we don't do it very well. But
that's a bit different story from what is proposed.
> How does the community know what applications we do test and we would like
> them to test?
>
I partly covered that above. But honestly, I think "telling community what
to test" will reach 1‰ of those reporting bugs, and it's not necessarily a
problem and that they don't even need to care about it. It doesn't matter
much what we test and what we don't. There are ton of bugs everywhere, you
trip over them all the time. They are so many even in those primary
deliverables, and countless in less visible environments and apps. When I
started with Linux and OSS, I simply reported a bug every time I found
something not working in those apps and environments I regularly used.
That's the easiest thing the community can do to help QA, and they don't
need to know or care about any test plans, test cases, release requirements
or whatever.
> We will come up with a list, we revise it, perhaps get five applications
> (perhaps ten, I don't know) and we tell them. *We will make criteria for
> it*. So at least the minimum functionality will be tested and bugs filed.
>
>
>> And here's the overloaded term use. When you say "should go from core
>> apps", are you forbidding Workstation SIG to define Boxes as their core
>> app? I don't think you want to their their decision power over their own
>> spin, but I'm trying to show how easily this can get misunderstood.
>>
>>
>>>
> See the paragraph above, this is a huge misunderstanding here. For
> Workstation, we already test basic functionality for everything, not just
> those "core applications". If they want to have Boxes in Workstation, hell
> yeah. We will test it.
>
The point is, you bound together your core apps with higher quality
standards. If you don't allow SIGs to include additional apps of their
choice (e.g. gnome-boxes) to this higher quality bar ("this app must work
great, or we don't want to release"), it's a bad proposal. That's why I
said the two concepts should not be bound together, or the core apps
definition should be strictly per spin and not universal.
> But I do not see a point why an LXDE spin should care about virtualization
> in the basic package set. My logic is, that when I do not want to install
> Workstation because my computer is not capable running it, so it will not
> be capable running virtualization, either, and I definitely do not want
> services like libvirtd eating my memory.
> The "core applications" however must ensure that when a "first-time" user
> runs it, he will be able to find some apps to start with in the menus so
> that they could use the environment without having to go to terminal right
> away.
>
>
>
>>
>> here's a list A that contains all cross-distro core apps that must be
>> present, and here's a list B that contains all Workstation SIG' approved
>> apps that are subject to higher quality standards; or the cross-distro core
>> apps concept should be ditched and every spin should define their own list
>> of apps and then it would make sense to require the apps to be present
>> *and* subject them to higher standards at the same time.
>>
>
> Yes, the "core applications" I am talking about are not those that
> Workstation SIG have approved for Workstation. This is not about the
> Workstation, because it has everything it needs. This is about the other
> DEs. And yes, in that case, we would have two lists, one - type of
> applications that we would look for in all spins (in Workstation this is
> already covered, so there is no need to change anything).
> And the too quality approaches, when I say that an application should have
> "basic" functionality and I start "gnome-terminal" (just an example), it
> lets me do my CLI jobs just fine, but it will crash when I click on "Open
> new tab". Is it still basic functionality? Or is it some "enhanced
> functionality"? For a core application, this would have to work anytime.
> For just an application, this would be a matter of discussion on a blocker
> review meeting, for instance.
>
>
>>
>> I imagine we could make a new criterion saying that core apps (defined by
>> that particular WG, this is not what you proposed) must work well, i.e. all
>> commonly used functionality must be bug-free (as opposed to just basic
>> functions).
>>
>
> This is exactly what I think I have proposed. My point is this:
> We are QA, which means that we care for better quality. We cannot dictate
> to anybody. But, if we are united in our stands, discuss what quality
> criteria we could use for it and start filing certain bugs according to
> those criteria,
>
Maybe you didn't mean it as it sounds, but just a note: bugs should be
filed regardless of criteria or some other definitions. Criteria just
decide when the bug is blocking (and that's when we "dictate to others").
> maybe the people in various spin SIGS will notice and do something about
> it. Maybe we can recommend things to them. Maybe they will hear us. Maybe
> not - but that's fine, we do not block on them. However, we could care for
> better quality even for those non-blocking stuff.
>
>
>> That would increase the standards for them, but it would still be a
>> judgement call in exactly the same manner, and I don't think we can go
>> around that. And/or we can always defer to a particular SIG in such a
>> contentious case and let them decide whether they want to release it like
>> that or not, instead of making a group vote. (Historically though, we've
>> mostly demanded higher standards than Workstation WG themselves, so this
>> approach might not be pleasing for everybody. Just a side note.)
>>
>
> The proposal was a part of the QA test list. So, the questions was ... do
> we, as QA, believe that a little bit increased activity with non-blocking
> spins can help make the Fedora feel better, or do we not believe in it. I
> do. But if it is just me, the only thing I can do is, as you are
> suggesting, keep testing it (when I have spare time) and keep filing bugs.
> And since you are the only one who actually responded to it, I guess it is
> exactly this case.
>
I wanted to say "sure it would make those spins better", but it largely
depends on whether there any actual developers available to fix those bugs
(in time). And I'm quite afraid about that for niche environments. That's
why I prefer trying it first and make processes around it later. Otherwise
it can happen you make architects create plans for a nice sky castle in
your mind, only to find out later that there are no masons out there.
The second thing to consider is that you're always doing something at
expense of something else. The new thing should either be more valuable, or
a passion project.
Regarding the size of the community that could be influenced by a new
optional test case in the matrix, I'm afraid that's quite small. I'd say an
easy-to-read guide in "how can I help?" section on our wiki could be more
visible.
>
>
>> OK. But I think we can intuitively guess which apps are more important
>> than others, or can't we?
>>
>>
>
> We do. But do the community people, especially newbies, know it? I though
> that we wanted easy testing for community members. This might be one of
> them.
>
>
_______________________________________________
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
