[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Reproducible-builds] Usefulness of periodic reproducible builds e-mails

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?


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: