Thanks for taking a look. I see the role of the CI setup as complementary: I expect that people will still build packages locally as they work on the packages. That path will continue to cover the debian/* part of the package. The remainder (fit into the archive) will be covered by the CI. In the worst case, the issue will be caught on the buildds (provided one uses source-only uploads).
Regarding the amount of work required to make packages buildable directly with the Go tool, have a look at the examples I listed at the bottom of the document. I don’t expect to spend more than 15 minutes per package, and I can volunteer to do the initial fixes. We need to be on the same page regarding the longer-term strategy, though, otherwise packages will degrade quickly. Does that address your concern? On Mon, Feb 19, 2018 at 3:56 PM, Martín Ferrari <[email protected]> wrote: > Michael, > > On 19/02/18 09:25, Michael Stapelberg wrote: > > I have spent the last two weeks on a different approach to our CI setup, > > published the current version of the tools just now and added a document > > to our website (not linked from the main page yet until I have some > > feedback). > This is a great initiative, thanks! > > Now, my main objection is to using the go tool directly and skipping the > debian build system. I understand this is faster, but it also means that > we could be missing problems in the debian files themselves, and that > some packages will either fail or require a lot of work to avoid having > any customisation in debian/rules. > > > -- > Martín Ferrari (Tincho) > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
