On Saturday, 6 August 2016 at 19:46:52 UTC, Seb wrote:
That are excellent news!
1) Send the packages a notification about the build error (e.g.
Github comment) - this should probably be tweaked a bit, s.t.
it doesn't spam too often for still broken packages
I was thinking about having people register for notifications
2) Allow easy, manual build of special branches for the core
I need something similar for dev/testing purposes as well. Since
I am using digger it is really easy to build whatever dmd + pull
request is needed. Problem is controlling access.
3) Once you have the API
a) (try to) get a shield badge (-> http://shields.io/)
Nice find. Will use.
b) Make the data available to the dub-registry (->
4) Assess the quality of the unittests. Probably the easiest is
`dub test -b unittest-cov`, and then summing up the total
coverage of all generated .lst files
I am not sure this is a good idea. Besides the fact that coverage
doesn't correlate with quality, it is outside of the purpose for
this tool (identifying dmd regressions and identifying broken
5) Log your daily "broken" statistics - could be a good
indicator of whether your hard work gets acknowledged.
I rather hear it from people than seeing it in the stats :)
6) Regarding linker errors - I can only redirect you to the
open DUB issue (https://github.com/dlang/dub/issues/852) and
DEP 5 (https://github.com/dlang/dub/wiki/DEP5).
It is an open problem and I don't wont to solve it. For now I
think I will just install the most important ones and just accept
that not all packages will be build.
On another note, I do think the dub package definition could use
some extra fields. Like compatible platforms and compatible dmd
versions. Take vibe.d for instance, it is specifically build for
certain dmd versions and it makes no sense for dubster to try to
compile it with an unsupported version. Also, it allows dub
itself to notify you of incompatible packages w.r.t. the
installed compiler. Same idea for platform.