On 19 March 2017 at 19:37, Stephen John Smoogen <smo...@gmail.com> wrote:
> I think one of the big disconnects here is that Tomasz seems to see > that someone who 'owns' a package is a top notch developer who is > going to know that package completely and care about the warnings and > such spat out. The myth of the Debian developer and all that. Versus > the fact that many packages are only inside of Fedora because someone > wanted some other package. > Even if skills of someone who is packager of package XXX are not enough to fix some compilation warnings still such person can send email to source tree mainterner "Hi. I'm Fedora packager of package XXX and after last build on Fedora official builders I've spotted that new version which you just released produces some new/strange compilations warnings. My C programming skills are not enough to review and fix those warnings. Please have look on last build log <here_url_to_kiji>. Thank you.". In other words: automatically counted warnings if increased since prev build may send signal to packager to review and for example contact with source tree maintainer(s) to DoSomething(tm). Simple .. even if someone cannot fix or take care of some even minor issues/warnings if such signal will be not produces will receive signa "something is going wrong here". If spec file will have SourceMaintainer: field with email address of the maintainer(s) and they will agree to receive summary record with build stats it could receive email which may have look like: *Package: XXX* *Version: Y* *Release: Z* *List of patches: <list of urls to git repo pointing to each applied patch in this build>* *Spec file: <url in git repo to spec file where is lat %chagnelog entry informing why build was requested>* *Number of build warnings: NNN * *Change in number of warnings since last build: [+|-] MMM* *Full build log: <url to build log>* Last 3 lines could be with multiple numbers per arch. In scenario with additional sec file SourceMaintainer field with contact such short record could be sent *automatically* without wasting time of Fedora packager. Such platform creates metrics. On top of raw metric can be added alarming layer. I can easy imagine that to monitor such metric can be used even tool like zabbix. Zabbix an send automatically email messages about alarms. In other words to monitor such things can be used standard monitoring tools. If packager will add in next release some patch with such automatically sent notification source tree maintainer could be informed about this. Source tree maintainer can read last %changelog entry and learn about what and why (bugzilla ticket number) was just added new patch. Package maintainer will waste *zero seconds* to pass such detail(s) to upstream source tree maintainers. Write one time explanation in %changelog why new patch has been added and use this record automatically in many places .. And again: counting those errors per whole distro packages set may show grap on time scale with single factor which more or less will be correlated with whole distribution heath. Development tools maintainers like compilers may observe they changes in for example gcc/g++ how many new issues some new method of raising some compile time warnings exposed new issues in existing code. Again .. with data collected in zabbix define presentation layer with graph showing some interesting changes may be produced with few clicks without writing single piece of code in any programing language. Fedora now has tenths thousands of packages. With growing number of those packages linearly is growing potential number man/hours on even communicating with source trees maintainers to take care of sme issues. Such automation framework/infrastructure should remove from package maintainers responsibility to communicate with those maintainers allowing them to take care other/more interesting aspects of working on on thing like Linux distribution. I know that implementing above it is a cost. However I think that very quickly such investment will be fully paid back, Source tree maintainers who will agree to participate in such flow of informations may receive probably not more than few such automated email notifications per month. If all data will be somehow collected part of the web frontend koji interface may be generate on some page such stats to c&p manually by packager and send somewhere such short report. Such formalised record of data may be even used to raise automatically tickets about for example suddenly growing compile time warnings in other BTSes like Gnome BTS. Not every OSS project now is ready to have such automated communication but many already have enough infrastructure to implement connection with koji and own BTSes. Again: zabbix could be used here easy to organise such connections almost OOTB. Using zabbix to monitor not hosts but packages may be very interesting thing of using this tool on some unusual area :) Packages as hosts. Set of metrics per package in template (easy to add/change new metric per package). Very easy to use platform to produce sophisticated summary reports and build on top of those summary data next ayer high level metrics .. Connecting zabbix with other Fedora components over zabbix REST API ... *But again .. to start feeding data about packages states to monitoring tools proper interface needs to be defined/created first.* When such interface will be created strongness of the set of possibilities how to use it is like continuum. If zabbix will be used in above scenario SourceMainainer rpm spec field will be not necessary because such contacts and full customization of automated communication can be held in zabbix monitoring configuration. Zabbix provides full transport media definition to customize transporting messages (even using pigeons) by anyone who will have account in zabbix. Zabbix can authenticate users using LDAP/Kerberos so its integration with existing Fedora infrastructure can be done without writing single line of code. As someone who is using zabbix and time to time actively helping other people using it +10 years (upper right corner on https://www.zabbix.com/forum/member.php?u=1703), and contributing time to time some small fixes to it I can say that probably choosing zabbix here would be best choice. kloczek: -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
