On Friday, September 7, 2018 8:36:11 AM MDT 0xEAB via Digitalmars-d wrote: > On Thursday, 6 September 2018 at 20:08:08 UTC, Jonathan M Davis > > wrote: > > On Thursday, September 6, 2018 12:35:06 PM MDT Joakim via > > > > Digitalmars-d wrote: > >> Ah, but would you actually pay for such a service to be set up? > >> > >> https://forum.dlang.org/thread/acxedxzzesxkyomrs...@forum.dlang.org > >> > >> It's all well and good to hope for such services, but they're > >> unlikely to happen unless paid for. > > > > That's actually something that I could see happening without > > anyone being paid to do it, but it's much more likely to get > > done in a timely manner if someone is paid to do it, and it's > > arguably critical enough for the dub ecosystem that it's > > something that the Foundation should pay someone to do. > > > > - Jonathan M Davis > > The software itself is pretty simple (besides it has to deal with > some DUB bugs). It would just need someone to run it. If running > it every DMD release is sufficient and if it doesn't need to be > automated, it won't be such a big deal anymore. > > By the way, I'm currently playing around testing DUB packages > with my prototype.
I don't see how such a system could work very well if it's not automated. Simply doing it with every release of dmd means that newer packages won't be tested, and it would force someone to take the time to run stuff every dmd release, which they may or may not have time to do. IMHO, it really only makes sense to set up something automated. I would expect that any time code.dlang.org detected that a package had a new version (or a package was added), the new versions would be tested. What's somewhat more of an open question is how new compiler releases should be handled. Aside from the issue that _every_ package then potentially needs to be tested (which could take a while), there's the issue of which versions to test. Testing every release of a package would be overkill, but simply testing the latest isn't necessarily enough. Also, there's the question of what it even means to test each package to verify that it's working. Does that mean running the unit tests? Not all projects run them the same way, and it could be pretty expensive to run the tests for all packages on code.dlang.org. And of course, that assumes that the package even has any unit tests to begin with. So, should testing the package just mean that dub build works? That will catch the really basic problems, but it won't usually catch problems in templates and could easily miss other types of problems - though maybe it's enough. Regardless, it's going to need to be made clear what it means that code.dlang.org claims that a package works with a particular version of the compiler. All in all, while this seems like a great idea, the more I think about it, the more it seems like it could get pretty thorny when sorting out all of the details. - Jonathan M Davis
