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
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 . and sync from there to koji to build (s)rpm.
We in QA could then use  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.
More information about the test