Re: How to configure a network bridge from script ?

[Alexander Todorov]

На 12.05.2016 в 15:32, Phil Sutter написа:

Hi,

On Thu, May 12, 2016 at 02:47:19PM +0300, Alexander Todorov wrote:

# cat /etc/sysconfig/network-scripts/ifcfg-enp1s0f0
Generated by dracut initrd


The line above is supposed to be a comment.



OK, fixed that then I got:

# systemctl status network.service
● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network)
   Active: failed (Result: exit-code) since пт 2016-05-13 02:33:54 EDT; 36s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 2189 ExecStart=/etc/rc.d/init.d/network start (code=exited, 
status=1/FAILURE)


май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]: Could not load 
file '/etc/sysconfig/network-scripts/ifcfg-lo'

май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]: [  OK  ]
май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]: Bringing up 
interface enp1s0f0:  [  OK  ]
май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]: Bringing up 
interface enp1s0f1:  Error: Connection activation f...tion.

май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]: [FAILED]
май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]: Bringing up 
interface br0:  [  OK  ]
май 13 02:33:54 amd-dinar-02.lab.bos.redhat.com systemd[1]: network.service: 
Control process exited, code=exited status=1
май 13 02:33:54 amd-dinar-02.lab.bos.redhat.com systemd[1]: Failed to start LSB: 
Bring up/down networking.
май 13 02:33:54 amd-dinar-02.lab.bos.redhat.com systemd[1]: network.service: 
Unit entered failed state.
май 13 02:33:54 amd-dinar-02.lab.bos.redhat.com systemd[1]: network.service: 
Failed with result 'exit-code'.

Hint: Some lines were ellipsized, use -l to show in full.



And

# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group 
default qlen 1000

link/ether 00:00:1a:1a:94:70 brd ff:ff:ff:ff:ff:ff
inet 10.16.42.33/21 brd 10.16.47.255 scope global dynamic enp1s0f0
   valid_lft 77820sec preferred_lft 77820sec
inet6 2620:52:0:102f:200:1aff:fe1a:9470/64 scope global noprefixroute 
dynamic
   valid_lft 2591924sec preferred_lft 604724sec
inet6 fe80::200:1aff:fe1a:9470/64 scope link
   valid_lft forever preferred_lft forever
3: enp1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN 
group default qlen 1000

link/ether 00:00:1a:1a:94:71 brd ff:ff:ff:ff:ff:ff
4: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
group default qlen 1000

link/ether 42:61:9f:68:1d:85 brd ff:ff:ff:ff:ff:ff


--
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

How to configure a network bridge from script ?

[Alexander Todorov]

Hi guys,
I'm having trouble starting a network bridge from a script without restarting 
the server.


I am following this doc in order to configure a bridged network on a Fedora 23 
Server host:


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Network_Bridging_Using_the_Command_Line_Interface.html#sec-Create_a_Network_Bridge


my config files look like this:

# cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=dhcp
DELAY=0

# cat /etc/sysconfig/network-scripts/ifcfg-enp1s0f0
Generated by dracut initrd
NAME="enp1s0f0"
DEVICE="enp1s0f0"
ONBOOT=yes
NETBOOT=yes
UUID="58081eef-9d1f-48db-a565-65f45bd1c6e8"
IPV6INIT=yes
BOOTPROTO=none
TYPE=Ethernet
BRIDGE=br0


After that I do:

# systemctl restart network
Job for network.service failed because the control process exited with error 
code. See "systemctl status network.service" and "journalctl -xe" for details.


# systemctl status network -l
● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network)
   Active: failed (Result: exit-code) since ср 2016-05-04 10:33:32 EDT; 2min 
43s ago

 Docs: man:systemd-sysv-generator(8)
  Process: 1412 ExecStart=/etc/rc.d/init.d/network start (code=exited, 
status=1/FAILURE)


май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com network[1412]: [  OK  ]
май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com network[1412]: Bringing up 
interface enp1s0f0:  /etc/sysconfig/network-scripts/ifcfg-enp1s0f0: line 1: 
Generated: command not found

май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com network[1412]: [  OK  ]
май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com network[1412]: Bringing up 
interface enp1s0f1:  Error: Connection activation failed: No suitable device 
found for this connection.

май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com network[1412]: [FAILED]
май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com network[1412]: Bringing up 
interface br0:  [  OK  ]
май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com systemd[1]: network.service: 
Control process exited, code=exited status=1
май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com systemd[1]: Failed to start LSB: 
Bring up/down networking.
май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com systemd[1]: network.service: 
Unit entered failed state.
май 04 10:33:32 amd-dinar-02.lab.bos.redhat.com systemd[1]: network.service: 
Failed with result 'exit-code'.



After the failure the network config looks like this:


# ip a s
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp1s0f0:  mtu 1500 qdisc mq state UP group 
default qlen 1000

link/ether 00:00:1a:1a:94:70 brd ff:ff:ff:ff:ff:ff
inet 10.16.42.33/21 brd 10.16.47.255 scope global dynamic enp1s0f0
   valid_lft 86204sec preferred_lft 86204sec
inet6 2620:52:0:102f:200:1aff:fe1a:9470/64 scope global noprefixroute 
dynamic
   valid_lft 2591805sec preferred_lft 604605sec
inet6 fe80::200:1aff:fe1a:9470/64 scope link
   valid_lft forever preferred_lft forever
3: enp1s0f1:  mtu 1500 qdisc mq state DOWN 
group default qlen 1000

link/ether 00:00:1a:1a:94:71 brd ff:ff:ff:ff:ff:ff
4: br0:  mtu 1500 qdisc noqueue state DOWN 
group default qlen 1000

link/ether 16:db:ac:3b:24:d4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::14db:acff:fe3b:24d4/64 scope link
   valid_lft forever preferred_lft forever


If I reboot the system the bridge appears to be up and running:

**after reboot**

# ip a s
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp1s0f0:  mtu 1500 qdisc mq master br0 
state UP group default qlen 1000

link/ether 00:00:1a:1a:94:70 brd ff:ff:ff:ff:ff:ff
3: enp1s0f1:  mtu 1500 qdisc mq state DOWN 
group default qlen 1000

link/ether 00:00:1a:1a:94:71 brd ff:ff:ff:ff:ff:ff
4: br0:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000

link/ether 00:00:1a:1a:94:70 brd ff:ff:ff:ff:ff:ff
inet 10.16.42.33/21 brd 10.16.47.255 scope global dynamic br0
   valid_lft 86391sec preferred_lft 86391sec
inet6 2620:52:0:102f:200:1aff:fe1a:9470/64 scope global mngtmpaddr dynamic
   valid_lft 2591988sec preferred_lft 604788sec
inet6 fe80::b496:e5ff:fe89:49e3/64 scope link
   valid_lft forever preferred_lft forever



This is with systemd-222-14.fc23.x86_64 

OT: Looking for examples of badly written bug reports

[Alexander Todorov]

Hello everyone,
I'm working on beginner QA and Automation training curricula for a local hack 
school in Sofia (https://github.com/atodorov/QA-101). I'm looking for examples 
of badly written bug reports which students can read and discuss what 
information is missing from them (e.g. why are they badly written).


Bugs can be on any bug tracker, not necessarily bugzilla.redhat.org. Strong 
favor for Mozilla, Gnome or GitHub issues in particular. They only need to be 
publicly accessible.



If you have any such examples please send them to me.


Thanks,
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Wiki pages: Missing tests in %check and missing upstream test suites

[Alexander Todorov]

На 27.02.2014 18:14, Christopher Meng написа:

Interesting :

fedora-release-notes

***-fonts

Can someone point me how to test them?





See amiri-fonts, gnu-free-fonts and thai-scalable-fonts. These appear to have 
some sort of testing available in the source and all three seem to be different. 
Maybe that will give you a place to start.


Otherwise look at the bugs for a particular package (wiki updated with links to 
Bugzilla) and figure out what kind of bugs are the most common ones. If there's 
a pattern it is likely possible it can be automated.



--
Alex


--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Wiki pages: Missing tests in %check and missing upstream test suites

[Alexander Todorov]

Hi folks,
thanks for your feedback in the last few days. I've created two wiki pages about 
packages which don't execute their tests in %check:

https://fedoraproject.org/wiki/QA/Testing_in_check

and another one for packages which don't seem to have test suites at all:
https://fedoraproject.org/wiki/QA/Missing_upstream_test_suites


My intent is for these pages to serve as a source of working material for Fedora 
volunteers.


Note: there are some false negatives which I still haven't filtered out - work 
in progress.



Please forward this to anyone who may be interested to work on these items as we 
need lots of hands to make any significant improvements!

(In particular I will soon teach to students and will point them here).


Any comments and proposals are welcome!


Thanks,
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to calculate priority for missing tests or %check

[Alexander Todorov]

На 26.02.2014 17:19, Adam Jackson написа:

On Wed, 2014-02-26 at 09:07 -0500, Josh Boyer wrote:


Except the kernel.  Please exclude it from all of this.


Also: xorg-x11-server, xorg-x11-drv-*, libdrm, libpciaccess, mesa.  Any
reasonable amount of testing on those is going to require more hardware
access than is feasible at rpmbuild time.




Adam,
just for completeness - libpciaccess doesn't seem to have a test suite. Do you 
mean to exclude it from the effort of creating one as well, or only exclude 
reports for missing %check?



Btw the URL field in the spec file should be updated to
http://cgit.freedesktop.org/xorg/lib/libpciaccess/  


--
Alex

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Wiki pages: Missing tests in %check and missing upstream test suites

[Alexander Todorov]

На 27.02.2014 16:18, Richard W.M. Jones написа:


Attached is a proposed patch to the spec file.  I ran this under
auto-buildrequires to see if it would need any extra BRs, but auto-br
didn't find any.



Richard,
can you point me to what auto-buildrequires is, where it lives and how do I use 
it? I don't seem to have it on my system or I'm blind and don't know where to 
look for it.





and another one for packages which don't seem to have test suites at all:
https://fedoraproject.org/wiki/QA/Missing_upstream_test_suites


virt-viewer is mentioned in this list.  Not sure how that could be
meaningfully tested since it requires an X11 display and a network
connection to a VM.



Mock this :). Of course it depends on the nature of bugs which are usually filed 
against virt-viewer and mocking could be just an overkill (or not at all possible).



PS: I will update these wiki pages with links to bugzilla.


--
Alex


--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

May I file 1000 bugs aka upstream test suite tracking

[Alexander Todorov]

Hi guys,
(note: devel, packaging and test lists) previously I've done a little experiment 
and counted how many packages are likely to have upstream test suites and how 
many don't:

http://atodorov.org/blog/2013/12/24/upstream-test-suite-status-of-fedora-20/

In general around 35% do have test suites, the rest don't.

My goal is to bring down the number of packages which ship without any sort of 
test suite inside their code base.


The first step is to identify them and track them in Bugzilla.


My question is:
**Is everyone, especially package maintainers OK with me filing 1000+ bugs ?**


Last time I did so (around 100 bugs) it got a few people unhappy so better ask 
this time!


If you are unhappy seeing such many bugs and having your mailbox full with 
notifications from Bugzilla please reply with a better proposal and why do you 
consider it better.



Thanks,
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking

[Alexander Todorov]

На 21.02.2014 16:27, Richard W.M. Jones написа:

Is it correct that you're only going to be filing bugs when upstream
tarballs already contain test suites, but they are just not enabled in
the Fedora package?


Hi Richard,
I meant just the opposite. However I will also do what you suggest but this will 
result in far less number of bugs (probably around 100).


I want to track which packages *DO NOT* have any tests and later be able to 
focus on creating them (be it working with volunteers, GSoC participants or 
whoever is willing to step up to this task).


I don't intend to force package maintainers to write tests if they don't want to 
(or can't).



--
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking

[Alexander Todorov]

На 21.02.2014 16:55, Daniel P. Berrange написа:


If you have code that can fairly reliably detect whether a test suite
exists in the source tar.gz, then I think you would be justified
in filing bugs for spec files which have not enabled the test suite.



At present I'm aware of 11 different location (directory or file names) which 
represent tests. Not sure how accurate is this though.



What I wouldn't do is blindly mass file bugs against every package
and ask the maintainer to investigate whether the test suite exists
or not.


I try to avoid that to the extent possible.

--
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking

[Alexander Todorov]

На 21.02.2014 16:58, Tom Hughes написа:

On 21/02/14 14:57, Daniel P. Berrange wrote:

On Fri, Feb 21, 2014 at 02:53:55PM +, Tom Hughes wrote:

On 21/02/14 14:51, Alexander Todorov wrote:


I want to track which packages *DO NOT* have any tests and later be able
to focus on creating them (be it working with volunteers, GSoC
participants or whoever is willing to step up to this task).


Why would you file a bug in the Fedora bug tracker when the package
has no test suite upstream? That makes no sense - if the upstream
package has no tests then the bug belongs upstream not in Fedora.


I don't believe that is what he is proposing. I read it as meaning
filing bugs where upstream *does* have a test suite, but the RPM
specfile has not enabled it in %check.


That was what I thought he really meant originally, and that was what the wiki
page suggested, but it doesn't seem to be what he is saying in the message I
quoted.



Guys I can do both.

1) Report packages which *have* test suites but they are *not* executed in 
%check

2) Report packages which *don't* have any test suites at all.

1) is easy but I'm more interested in 2)

--
Alex

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: May I file 1000 bugs aka upstream test suite tracking

[Alexander Todorov]

Looks like reporting missing test suites in Bugzilla is not accepted. I guess 
it's just me who prefers Bugzilla compared to other media.


I *will use the Wiki* for this.


On the topic of tests not executed in %check I *will use Bugzilla* but Alexander 
Kurtakov brings up another angle - tests executed in %build. This needs more 
investigation. I will start a separate thread for it.



Thanks for your answers,
Alex

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: fedora in 2013

[Alexander Todorov]

На  6.01.2014 16:52, Matthew Miller написа:

Hi Fedora test and QA folks! I posted a (kind of long) message on Fedora devel
with some thoughts about the direction of the project in the next year. A
lot of it directly affects -- and is affected by, of course -- Fedora QA,
and the whole third section about increased automation is basically all
about QA/QE and release engineering.

I'm not going to repost this _everywhere_, but since this pretty big and
since this is one of the more active lists where members might not all be
following the devel list actively, I thought you wouldn't mind a pointer.

The thread is at
https://lists.fedoraproject.org/pipermail/devel/2014-January/193401.html,
and while it'd be kind of nice to have discussion in one place, I'm happy to
talk about it whereever. :)


Hi Matthew,
just a note for item 3. Continuous Delivery.

For this we need to improve testing, which is one of my personal goals for 2014. 
See info about initial upstream test suite status here:

http://atodorov.org/blog/2013/12/24/upstream-test-suite-status-of-fedora-20/

Email thread is here:
https://lists.fedoraproject.org/pipermail/test/2013-December/119637.html

Regards,
Alex

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Thoughts about Travis-CI integration

[Alexander Todorov]

На 18.12.2013 20:09, Tim Flink написа:

On a side note, it might be interesting to find out what percentage of
packages are running things in %check. I don't know what we would do
with that metric, but I think it would be interesting :)



Hi Tim,
I did a quick measurement and the number of packages which execute something in 
%check is around 30%. 35% is the number of packages which appear to have a test 
suite at all. More details here:

http://atodorov.org/blog/2013/12/24/upstream-test-suite-status-of-fedora-20/


Happy holidays,
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Thoughts about Travis-CI integration

[Alexander Todorov]

На 18.12.2013 20:09, Tim Flink написа:

On a side note, it might be interesting to find out what percentage of
packages are running things in %check. I don't know what we would do
with that metric, but I think it would be interesting :)



I have something in the works which can be modified to extract this info. It 
should be fairly easy to make a good guesstimate of the presence/non presence of 
test suites as well.  I think I'll start from here.



Does Fedora have its own CI infrastructure coupled with Koji ?


That depends on what you consider CI to be, I guess. I consider both
autoqa and taskotron to be forms of CI but not the exact same thing as
travis or jenkins.

Both autoqa and taskotron are designed to run various things based on a
package's state in either koji or bodhi.



Thanks, I have to look into these. I gave Travis as example because it is well 
known and because somebody else decided to make use of it in python-bugzilla.





I'm still unclear on what you're looking to do. Are you talking about
looking for test suites in package upstreams and running those tests,
regardless of whether they're run in %check during build? Are you
talking about creating and maintaining an out-of-band set of unit tests
for packages without an upstream unit test suite? Are you talking about
creating a set of package-specific functional/integration test suites
that are run when packages are built?



Pretty much all of these in the long term but I wanted to get a general feeling 
so I can concentrate the effort on something specific.



* For packages which have upstream test suites (e.g. parted) - contribute more 
tests where necessary; Ideally covering bugs reported against Fedora or RHEL for 
which there isn't a test case.


* For packages without upstream test suite my preference is to create one and 
contribute it back upstream. If upstream doesn't accept it and the package is 
critical enough maybe maintain that in the Fedora branch.


* Functional/integration test suites (e.g. using Beaker tasks) are less priority 
goal for the moment but also need to be considered. For some packages these are 
more suitable (e.g. anaconda), for others maybe not (e.g. pykickstart seems to 
have fairly good amount of unit tests).



Whatever the test suite(s) come out to be we need an environment(or 
environments) where to execute them and a method of starting the suite. I can 
see how some test cases are part of %check and can halt the build process and 
others are started async after the build and are left for Fedora QA and devel to 
investigate.


In the case of Travis, test runs are triggered by git commits and Travis is not 
connected to any build infrastructure from what I know. It provides the results 
to whoever is interested in them.







--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Thoughts about Travis-CI integration

[Alexander Todorov]

Hi folks,
this message sparked an interest:
https://lists.fedorahosted.org/pipermail/python-bugzilla/2013-December/000200.html

In addition to that I've inspected around 30 packages which seem to be missing 
an upstream test suite (a few have one but it is not automatically executed in 
%check section in the spec file).


I'm pretty sure many more packages are like this, I just didn't have the time to 
investigate all several thousands of them.



My idea is simple - starting after the holidays to call for help in writing test 
suites (or more test cases) for packages. This can be coupled with settings to 
execute them in Travis CI or another CI system of choice.




My questions are:

* What is the general feeling of using Travis CI in Fedora? It is well 
established in Ruby and Python circles but I know we like to keep dependency on 
external services to minumum.


Does Fedora have its own CI infrastructure coupled with Koji ?

Maybe deploy our own instance or contribute to Travis with a pool of systems 
sponsored by Fedora?


What to do with packages whose test suite is not suitable to be executed during 
build (e.g. due to requirements or limitations on the build servers) ?


What's your take ?

( Adding Tim Flink to CC to answer from the infrastructure side. )


* Are there any volunteers to join me in planning and coordinating this project? 
We need to somehow prioritize which packages need inspection and working on, 
count the available test cases, report bugs if missing, produce patches, etc. It 
will be a long run one and needs lots of work just because the great number of 
packages.



* Who else should I be talking to ?


Regards,
Alex
--
http://atodorov.org
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Should we update our bug reporting procedures/process ?

[Alexander Todorov]

Hi folks,
recently OpenSource.com published an article of mine explaining why users should 
take the extra step to submit a bug:

http://opensource.com/business/13/10/user-guide-bugs-open-source-projects


It is based on real event, which happened to me during Fedora test days last 
month. The comments after the article are very interesting. Please take a look 
at them.



Re-reading my article and comments today got me thinking if we need to change 
something wrt Bugzilla. It appears that users may be having difficulties with 
it. Any ideas, comments, rants?



Thanks,
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Should we update our bug reporting procedures/process ?

[Alexander Todorov]

На  1.11.2013 12:12, Jóhann B. Guðmundsson написа:


There is nothing in that area that is not already known or trying to be 
addressed.



I'm not aware of how are we trying to address this, can you point me to some 
wiki pages, proposals, etc?



--
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Let's stop using wiki for test results

[Alexander Todorov]

Folks,
I've participated both in Virtualization and GNOME test days this week and there 
is one thing that felt very strange and not easy to use for me.


GNOME test day results were recorded in the wiki, while Virtualization ones in a 
web app here:

http://209.132.184.192/testdays/show_event?event_id=7


IMO this web app is much easier and faster to use instead of the wiki. And it is 
not a full blown TCMS like Nitrate, with features that most of the people will 
not need.


I propose to make use of this web app for future test day results/bug tracking. 
And give it a name :).



Regards,
Alex
--
http://atodorov.org
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Let's stop using wiki for test results

[Alexander Todorov]

На 11.10.2013 17:03, Adam Williamson написа:

On Fri, 2013-10-11 at 13:42 +, Jóhann B. Guðmundsson wrote:


Hmm when was it decided that we should write our own app to replace the
wiki instead of trying to (re)use something other distribution are using?


Such as?



Just for the record:

https://fedorahosted.org/nitrate/


Nitrate is a full blown test case management system, however for the test days I 
think it is a bit too much.


--
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 20 Gnome Test Day, October 10th

[Alexander Todorov]

На  9.10.2013 15:50, Jan Sedlak написа:


Join IRC #fedora-test-day on FreeNode if you get into trouble.
Report all bugs preferably at upstream bugzilla [3] or Red Hat bugzilla [4].


Does this mean all apps will be latest  greatest ?

My experience with GNOME upstream is that if you are not using latest and 
greatest they just ignore bugs which are distro specific.


--
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Moving away from reporting to RH bugzilla and adopting pure upstream reporting mantra.

[Alexander Todorov]

На 24.09.2013 02:44, Jonathan Kamens написа:

2) Most Fedora users are not developers. If they have to jump through hoops to
figure out where to report bugs, then they won't report the bugs. The one-stop
shop that Red Hat bugzilla provides as a point of entry for all bugs that users
encounter in Fedora is a huge, huge, value-add service. Getting rid of it would
do catastrophic damage to Fedora's ability to get feedback about problems from
end users who aren't power users and developers. Is Fedora trying to simply
write off such users as irrelevant?


+1

I myself am an experienced QA and sometimes fail to file a bug against the 
correct component, let alone a user who just wants to report a problem so it is 
fixed the next time. How will users know where the upstream tracker is ? This is 
just too much to ask from them.



--
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Question: What are Fedora 20 test days business hours in Europe

[Alexander Todorov]

Hi guys,
I'll try to organize a few people locally in Sofia to participate in Fedora 20 
test days, currently interested in Virtualization Test Day and Gnome Test Day on 
Oct 8th and 10th.


My intention is to bring people together in a room and do some testing. During 
what hours in the European time zone there will be devel and other QA folks 
present on IRC?


The chosen venue where people will gather is available until 15:30 UTC due to 
another event.


Thanks,
Alex
--
http://atodorov.org
http://twitter.com/atodorov_
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Introducing myself

[Alexander Todorov]

Hi everyone,
I've briefly introduced myself at the Fedora QA meeting today, Repeating here 
for those who missed it.


I come from RedHat's Relase Test Team specializing in installation testing. I've 
been in QE for 6+ years already. I've been the RTT point person for RHEL 5 
almost since 5.0.


In the past I've tested Fedora on the OLPC XO laptop. My FAS/IRC username is 
'atodorov', see wiki User:Atodorov for more details.



I'm in the process of transferring some of my other tasks to other people and 
will free up some time for Fedora, initially the equivalent of 2 working days of 
the week.



I will be working with Kamil Paral to automate some of the installation related 
test cases and execute them regularly when TC are available starting tomorrow.


Long term I will be joining Fedora test days and try to organize a group of 
testers locally in Sofia to join FTD too.


I'm also willing to work on infrastructure related projects, I can do Python and 
Django but will cope with almost everything else. What I'd love to see is a 
Fedora QA Lab based on cloud architecture and open source components. Feel free 
to CC me on such related topics (I understand work is in progress but I'm still 
getting up to speed).



Ping me on IRC or via email, I answer most of the time fairly quickly.


Regards,
Alex
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test