Hi Emmanuel, On Dienstag, 29. September 2015, Emmanuel Bourg wrote: > > I agree and am wondering if we should actually do this, and limit > > (maintainer) notifications to unstable? What do you think? > Well, if I understood your "this graph is a lie" properly in your talks, > I think the reproducibility in testing isn't very interesting for now, > until the tool chain matures and we have really reproducible packages in > unstable. At this point the testing notifications will have much more > sense. Nope, I don't think you understood my "this graph is a lie" properly ;-) The graphs are "lies", because they don't show sid and stretch but (sid+our repo) and (stretch+our repo). There is a different reason why I think notifications for testing are "useless noise" (or "not so interesting information", if you prefer): in Debian, we fix things in sid and these fixes migrate to testing (=stretch), so once a package has become reproducible in sid it should also become reproducible in testing, once that version migrates to testing. If this doesnt happen it's almost certainly a bug in our test framework, but not a reproducibility issue in the package. And if the package ftbfs in testing, this is very sad, but IMO not appropriate to send a "reproducible builds project" notification for it - such problems should be detected elsewhere. It's nice if we gather that data, and we should also manually file bugs from that data, but I dont think we should generate automated notifications because as I tried to explain, if a package is fixed in sid, the fix will migrate to testing eventually. Thus we only really need to care about sid and testing will be good "automatically". > So yes, limiting maintainer notifications to unstable would be a good idea. I've limited notifications to unstable and experimental now, and also improved the code a bit that only one mail per is sent per source package in all suites, no matter how many status changes it had. But we should still improve it to allow individual subscriptions, and probably this is best done via tracker.d.o - does anybody know how to achieve that? cheers, Holger
Attachment:
signature.asc
Description: This is a digitally signed message part.