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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
