Drawing lessons from fatal SELinux bug #1054350
mattdm at fedoraproject.org
Wed Jan 29 14:26:26 UTC 2014
On Tue, Jan 28, 2014 at 06:42:52PM -0800, Adam Williamson wrote:
> Using the wiki as a TCMS is of course a gross hack, but it comes with a
> surprising number of advantages - see
Makes sense to me. I'm actually not opposed to using the wiki in this way,
but I think it highlights the need for _something else_ to be our
short-quick-easy documentation solution.
> > I wonder if it would help both
> > of these things to move the test plans to live in package git (right next to
> > the future taskotron scripts?
> Well, what would they look like, and how would you read them? What we're
They would be short text files. Possibly markdown. Something simple, though.
I hear you on the downside of having to have commit rights to the package in
order to work on test plans in git. That applies to the taskotron tests too,
though, doesn't it? Maybe we could use git submodules for this. (Where each
fedora package has a submodule consisting of its tests, both automated and
But like I said I'm not really opposed to continuing to use the wiki. Maybe
we just need an awareness campaign. (Some text in the bodhi.template from
fedpkg update would be a good start, I think. And on the New Update page in
the bodhi web interface. And definitely in
https://fedoraproject.org/wiki/Package_update_HOWTO -- I'll do that, as soon
as I have that coffee I didn't have when I said I was going to at the end of
the last message I sent.)
> > And, while clearly helpful, I think it suffers from a little bit of tl;dr.
> > Maybe we could embed summaries of each right into the Bodhi page?
> I'm not quite clear what you mean here - what's tl? Summaries of what?
I mean the links to the test cases shown in bodhi. In the context of trying
to get better feedback in bodhi, it would be nice if there were a summary of
each test right in the bodhi screen (not just its title). Then, there could
be a little dropdown to choose between "didn't try this aspect", "looked at
the thing in the summary; seemed okay" and "actually went through this full
test case". That would make it easy for people to be descriptive and honest
about what they actually tried.
Don't get me wrong -- the way it works currently is pretty awesome and just
making that more used would be great.
> > The other thing is that I think that in addition to the per-package test
> > cases, it would be good to encourage updates to include at least a line
> > about what is of particular interest to test in _this_ release. Sometimes,
> > that's the same as the update Details, but not always.
> It would indeed be nice if maintainers did this, though of course it's
> not relevant to the case we're currently considering (as the broken
> content in the update was a mistake and the maintainer didn't even know
> it was there, he'd hardly have been likely to highlight it for testing).
Yes, in this case the general test plans would have covered it. Hopefully.
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>
More information about the devel