----- Mail original ----- De: "Jakub Cajka" Hi Jakub > I think that it would be best if Nicolas could fold his proposal in to the original draft as > optional part for simple library/binary packages. Frankly, that's a lot of work and churn, I don't want the new parts to be refused because of something in the old parts, and I certainly do not want to spend weeks replacing bits only to put them back in and so on while people made up their mind on the things they want replaced or not. The new parts are pretty much autonomous and complete, they are sufficient to create working Fedora Go packages, they are ready for FPC review. If someone wants to extract the ready non discussion parts of the old page and get them approved I can work with him to merge both elements I didn't want to write about the old page, but since you put it on the table. It is full of digressions and elements of no evident applied value while packaging Go software. It's not an operational "how to do stuff" document it's a "here are various things you may like to know about Go that may or may not help you create Fedora Go packages, if they do not help you forget about it and run gofed". There are too many WIP non operational bits in the old pages to allow merging while in an approval process. And I'm sure any attempt to strip the WIP bits from my side will be met with energetic protests. People, if you want that page to be ever approved by FPC make it more focused and accurate. Remove anything that does not explain to a Fedora Go packager how to write a Fedora Go spec file and what to ask upstream Go projects in a Fedora packager role. And make sure what remains is succinct, easy to read, and applicable without undocumented holes or gofed magic. I know that's a lot of non-fun work. I did this work on the new page. I don't particularly *like* writing documentation. For every line I put in the new page, I had to ask myself "is the value to the Fedora packager sufficient to justify the time spend writing the text, formatting it, linking in the right place, proofing the result". I didn't put in stuff I could not justify cleaning up myself. If it was too much work to document it was either of insufficient value or better automated rather than explained in a manual process. Any part of the text that can not be finished or serves another role has no place in a guideline submitted to FPC. It should be nuked or moved to a separate wiki page. All the half-finished and non operational stuff in there is the reason the draft has been stuck in pre-approval stage for four years. Just put yourself in FPC's place, its mission is to confirm a guideline is ready to be used by the average Fedora packager, not to produce it from half-finished half-related messy notes of the domain experts. > As his proposal doesn't cover at least two major use cases, i.e. separate packaging of tests(they > have no place in devel package as they artificially inflate build root size) At this point of time my mind is pretty much set. I won't do separate packaging of tests because: 1. that raises complex dependency handling questions 2. the average Go project test code is full of crufty junk 3. the average Go test depends on assets not tracked within Go 4. Go is not designed to separate elements shipped in the same directory 5. no one could answer when I asked the *three* Fedora lists what they were using the existing test packages for 6. from what I've seen many of the existing test packages simply can not work because they fail to include elements they need 7. even core Go people refuse to touch the subject with a 10 foot pole. Sam Boyer tried to demo a very small part of what would be necessary this week end at FOSDEM and this part of his demo *failed*. I don't have the level of Go understanding Sam Boyer Has. I am ready to work with people who want to make separate test packages and I tried very hard to make them possible in the future but I won't spend time trying to ship half-baked stuff that does not work and that no one has a need for. The proposed patterns strip test code from devel packages so build root sizes are safe (except for the original package build root, since I *do* execute unit tests in check, and they pull their deps in the build root). You want to test one of my packages, fine, just rebuild it. That will run unit tests *and* build the project binaries (which are also a form of code testing, and a very thorough one at that). > and shipping pre-built shared libraries. The pre-build shared libraries the old guidelines refuse to build or document? Why exactly are you stating it's a major use case, Fedora is not doing it today. "By default, the standard golang compiler produces static libraries. There is little value in shipping these prebuilt, especially since these libraries are very specifically tied to the exact minor release of the golang compiler." "Presently the shared object libraries produced by GCC-Go are not usable" Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
