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

"J├│hann B. Gu├░mundsson" johannbg at gmail.com
Tue Sep 24 11:07:11 UTC 2013


On 09/24/2013 10:45 AM, Mateusz Marzantowicz wrote:
> Great idea, but how would one know all that upstream bug tracker URLs
> for all packages that are shipped with Fedora?
>
> Is there any tag in RPM package spec file that could be used to provide
> such information and are you planning to extend package descriptions so
> people can easily find upstream bug tracker URLs?
>
> Are there any plans to provide central information point (wiki, etc.)
> with all upstream bug trackers in place of old RH bugzilla?

We would have to build something like that as well as to how to debug 
these components.

Now there ofcourse is a different approach we could take as instead of 
always running after upstream and try to convince them to join our 
project we could move/migrate everything to github ( which is the 
largest social coding side afaik ), sync upstreams that dont already 
exist there to it [1]. and sync from there to koji to build (s)rpm.

We in QA could then use [2] harvest all the required info as well point 
reporters to report there.

 From a QA and developer standpoint the perfect pony could be for 
developers to attach a patch or reporters to press build it ( after 
patch has been provide upstream ) to be able to consume and test the fix 
the upstream maintainer provided without the overhead of knowing how to 
rebuild complete upstream ( which more or less is the inconvenience that 
will make reporters give up ).

That rebuild could then be deployed in an isolated container on top of 
btrfs subvolume, then tested and reverted easially if necessary or kept 
and the older instance thrown away.

Ofcourse the above could be something we would work towards against 
achieving here in QA in the next 2 years.

JBG

1. https://help.github.com/articles/syncing-a-fork
2. ttp://developer.github.com/v3/issues/

JBG


More information about the test mailing list