qa-devel January 2014

qa-devel@lists.fedoraproject.org

12 participants
82 discussions

Taskotron wiki page
by Kamil Paral 30 Jan '14

30 Jan '14

I created https://fedoraproject.org/wiki/Taskotron with some basic info and links, especially the quick start guide (kudos to Tim, this will surely be useful for many of us now). I also updated https://fedoraproject.org/wiki/QA/Tools with the list of our current projects. If you see something missing, please add it. Thanks.

4 13

Phabricator wiki page
by Kamil Paral 30 Jan '14

30 Jan '14

I created https://fedoraproject.org/wiki/QA/Phabricator and added some basic info and FAQ. I did that mainly because I was dealing with a flood of email notifications lately and wanted to reduce it. Some of you might find it helpful as well.

2 2

Making Phabricator More Public-Friendly
by Tim Flink 29 Jan '14

29 Jan '14

After a conversation with Kamil earlier today, I started looking into making our phabricator instance a bit more public friendly. Blender's instance is a good example of what I'd like to see ours do in terms of sidebar configuration and public landing page: https://developer.blender.org/ The awesome part is that the blender folks keep their modifications in a public repo as a branch of the upstream phabricator code, so figuring out how they got it to work is possible :) I was able to get the root uri display a similar page as what a logged in user can see: https://phab.qadevel-stg.cloud.fedoraproject.org/ It does require hacking on the code and as near as I can tell, the changes can't be done as an extension. The changes are pretty sane, though so I'll start a conversation with upstream on whether they'd be interested in a patch. Changing the sidebar layout, however, is a different story. The placement logic uses metadata in the code to determine where the icons are placed and how big they are. This is great from a dev point of view because you don't need any crazy logic for layout or need to update it all the time. Not so much if you want to change the default layout, though. If we want to change the default layout, I see 3 options: 1. maintain an out-of-band patch that either changes the application metadata so that the display works how we want or change the display logic so that it works differently. This is how the blender instance is set up - they changed the metadata in applications so that they would be rendered differently from the defaults. Not the prettiest thing ever but reasonably maintainable and effective. I suspect this would cause problems with any custom layouts that folks set, though. 2. hack a hard-coded default into the display logic, overriding the current logic-based defaults. This should allow for users to customize the sidebar as they want while not being a terrible hack. It would require more work and a decent understanding of the codebase, though. I also suspect that maintenance would be a bit more difficult. 3. Work with upstream (if they're interested) on a way to set a default layout for the sidebar. This would be quite a bit of work, assuming that upstream would even be interested in the functionality. It would be most likely to not cause maintenance headaches in the future, though. If we're going to change the sidebar layout, I'm of the opinion that option 1 is the best for us, for now. We're already on a tight deadline and I don't want to spend too much more time hacking on support tools right now. FAS auth integration is already going to take some work, so there's that task for the near future as well but phabricator already has persona auth support and I'm not expecting that task to be terrible. Thoughts? Tim

2 5

phab: auth providers
by Martin Krizek 22 Jan '14

22 Jan '14

I wonder if we should enable authentication through providers like GitHub instead of just username/password (and FAS in the future). This would make it easier for non-fas users to report bugs or contribute to the project. I also noticed that anonymous access to view tickets is possible but one need to know the link, is there a way to fix this? Any thoughts? Thanks, Martin

2 2

Phab: setting projects when creating a ticket
by Kamil Paral 21 Jan '14

21 Jan '14

I just tried to create a ticket in Phab. I understand that the Project field is similar to Component field that we used in Trac. (It's a bit unfortunate that a project can't be further separated into components). However, there's no text completion in that field unless you type in something. There's no list of projects nearby (unless you know which icon to click in Phab and find it in a separate page). I'm a bit afraid that people won't be able to report bugs in Phab unless it's easy to find "taskotron" or something through the Project field. Sure, I assume we can provide custom URLs which fill in the project field through GET arguments, but then you need to spread these links everywhere so that people don't find a different way to the system. Am I missing something?

2 1

proposed test cases autoqa -> phab migration
by Kamil Paral 21 Jan '14

21 Jan '14

I was asked to forward this to qa-devel. The tickets are already migrated, but I at least responded to Jan Pazdziora that FAS support should come to Phab soon. ----- Forwarded Message ----- From: "Jan Pazdziora" <jpazdziora(a)redhat.com> To: "Adam Williamson" <awilliam(a)redhat.com> Cc: qa-devel(a)lists.fedoraproject.org Sent: Tuesday, January 21, 2014 8:25:21 AM Subject: Re: [AutoQA] #220: Check domains of running services after installation On Mon, Jan 20, 2014 at 10:18:36PM -0000, AutoQA wrote: > #220: Check domains of running services after installation [...] > ---------------------+-------------------------------- > Changes (by adamwill): > > * resolution: => wontfix > * status: new => closed > > > Comment: > > Migrated to Phabricator: https://phab.qadevel.cloud.fedoraproject.org/T67 > > -- > Ticket URL: <https://fedorahosted.org/autoqa/ticket/220#comment:5> Hmm, so you are closing the tickets and creating new ones, in a system which apparently does not support FAS so everyone interested in being still informed about those tickets should create yet another account in yet another system du jour? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat

1 0

Re: [AutoQA] #367: Detect missing optional BuildRequires from Koji log
by fedora-badges 20 Jan '14

20 Jan '14

#367: Detect missing optional BuildRequires from Koji log --------------------+-------------------------------- Reporter: kparal | Owner: Type: task | Status: closed Priority: minor | Milestone: Future test cases Component: tests | Resolution: wontfix Keywords: | Blocked By: Blocking: | --------------------+-------------------------------- Changes (by adamwill): * resolution: => wontfix * status: new => closed Comment: Migrated to Phabricator: https://phab.qadevel.cloud.fedoraproject.org/T70 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/367#comment:1> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Re: [AutoQA] #264: Run eclipse test suite for new eclipse koji builds
by fedora-badges 20 Jan '14

20 Jan '14

#264: Run eclipse test suite for new eclipse koji builds --------------------+-------------------------------- Reporter: jlaska | Owner: Type: task | Status: closed Priority: minor | Milestone: Future test cases Component: tests | Resolution: wontfix Keywords: | Blocked By: Blocking: | --------------------+-------------------------------- Changes (by adamwill): * status: new => closed * resolution: => wontfix Comment: Migrated to Phabricator: https://phab.qadevel.cloud.fedoraproject.org/T69 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/264#comment:2> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Re: [AutoQA] #263: Run kvm-autotest test suite for new virt* koji builds
by fedora-badges 20 Jan '14

20 Jan '14

#263: Run kvm-autotest test suite for new virt* koji builds --------------------+-------------------------------- Reporter: jlaska | Owner: Type: task | Status: closed Priority: minor | Milestone: Future test cases Component: tests | Resolution: wontfix Keywords: | Blocked By: Blocking: | --------------------+-------------------------------- Changes (by adamwill): * status: new => closed * resolution: => wontfix Comment: Migrated to Phabricator: https://phab.qadevel.cloud.fedoraproject.org/T68 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/263#comment:1> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Re: [AutoQA] #220: Check domains of running services after installation
by fedora-badges 20 Jan '14

20 Jan '14

#220: Check domains of running services after installation ---------------------+-------------------------------- Reporter: adelton | Owner: Type: task | Status: closed Priority: minor | Milestone: Future test cases Component: tests | Resolution: wontfix Keywords: | Blocked By: Blocking: | ---------------------+-------------------------------- Changes (by adamwill): * resolution: => wontfix * status: new => closed Comment: Migrated to Phabricator: https://phab.qadevel.cloud.fedoraproject.org/T67 -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/220#comment:5> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel January 2014