[Fedora QA] #494: F25 Atomic Test Day

[Fedora QA]

#494: F25 Atomic Test Day
--+
 Reporter:  jasonbrooks   |   Owner:  tflink
 Type:  task  |  Status:  new
 Priority:  major |   Milestone:  Fedora 25
Component:  Blocker bug tracker page  | Version:
 Keywords:|  Blocked By:
 Blocking:|
--+
 We want to have a test day for Fedora Cloud / Atomic 25 on Oct 14. I've
 started a wiki page for the test day at
 https://fedoraproject.org/wiki/Test_Day:2016_10_14_Cloud.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Re: Resultsdb v2.0 - API docs

[Kamil Paral]

> On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral < kpa...@redhat.com > wrote:

> > ...
> 
> > What are the use cases? I can think of one - yesterday Adam mentioned he
> > would like to save manual test results into resultsdb (using a frontend).
> > That would have no ExecDB entry (no UUID). Is that a problem in the current
> > design? This also means we would probably not create a group for this
> > result
> > - is that also OK?
> 

> Having no ExecDB entry is not a problem, although it provides global UUID for
> our execution, the UUID from ExecDB is not necessary at all for ResultsDB
> (or the manual-testing-frontend). The point of ExecDB's UUID is to be able
> to tie together the whole automated run from the point of Trigger to the
> ResultsDB. But ResultsDB can (and does, if used that way) create Group UUIDs
> on its own. So we could still create a groups for the manual tests - e.g.
> per build - if we wanted to, the groups are made to be more usable (and
> easier to use) than the old jobs. But we definitely could do without them,
> just selecting the right results would (IMHO) be a bit more complicated
> without the groups.

> The thing here (which I guess is not that obvious) is, that there are
> different kinds of UUIDS, and that you can generate "non-random" ones, based
> on namespace and name- this is what we're going to use in OpenQA, for
> example, where we struggled with the "old"design of ResultsDB (you needed to
> create the Job during trigger time, and then propagate the id, so it's
> available in the end, at report time). We are going to use something like
> `uuid.uuid3("OpenQA in Fedora", "Build Fedora-Rawhide-20160928.n.0")`
> (pseudocode to some extent), to create the same group UUID for the same
> build. This approach can be easily replicated anywhere, to provide canonical
> UUIDs, if needed.

> Hope that I was at least a bit on topic :)

Very much. Thanks for an exhaustive answer. 

> So, what's the decision? I know I can "guesstimate", but I'd like to see a 
> group consensus before I actually start coding. 

I'll just summarize here that we discussed this during Monday's qa-devel 
meeting and reached consensus that keeping ref_url in the group (as it used to 
be) is the current way forward. 
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Re: What to do with fedora-qa (fedorahosted is dying)

[Kamil Paral]

> > Phabricator works well with remote repos, and I don't think there's
> > any strong advantage in using local Phab repos. On Pagure we will get
> > more visibility for the projects, easy forking, etc. Also certain
> > simple repos (like the one above) can be completely fine with Pagure
> > issue tracker and thus don't need to be configured in Phab (the UI is
> > more difficult there for filing new bugs). I'd go with Pagure, for
> > all our projects.
> 
> In general I agree, I'd be happy for us to move pretty much everything
> into pagure. The only potential issues I see are:
> 
> 1) What about issue tracking for the projects where we currently use
> Phab? For e.g., if we want to keep tracking issues/tasks in Phab
> exclusively, can we disable Pagure issue tracking (and make sure people
> can easily find their way to Phab issue tracking from Pagure?)

You can disable issues in project settings. I don't think you can add a note to 
redirect people elsewhere, we can post a RFE or we can simply make that 
information visible in project README (which is shown by default).

The question whether we want to actually disable issues for certain projects or 
have several places to file them (pagure and phab) is a different matter. I 
guess we'll decide that on case-by-case basis.

> 
> 2) Similarly for pull requests - do we want to have parallel workflows,
> accepting both Pagure pull requests and Phab diffs? Or if we don't, can
> we disable Pagure PRs while providing sufficient breadcrumbs to get
> people into the Phab workflow?

Yes, PRs can be disabled in settings as well. Again, I think this might be 
different for each of our projects and we'll probably decide individually.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org