On Tue, Feb 25, 2020 at 12:59:39PM +0100, Vít Ondruch wrote: > > Dne 24. 02. 20 v 17:48 Pierre-Yves Chibon napsal(a): > > Good Morning Everyone, > > > > This topic has already been discussed a few times over the past month, but Adam > > Saleh, Nils Philippsen and myself have had the opportunity to invest some time > > on it with the hope of making the packager's life simpler as well as making it > > easier to build automation around our package maintenance. > > > > We have investigated a few ideas, the full list with their pros and cons can be > > found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev > > If you have any questions about some of these, please ask them, we'll be happy > > to answer them and potentially complete this document. > > > > > > For both the release and the changelog fields we believe using RPM macros would > > satisfy the requirements we have for opting-in/out: > > - You can easily opt-in by using the macros > > - You can easily opt-out by removing the macros from your spec file > > > > > > For the changelog, we believe we have a potential good solution: > > - The changelog will be automatically generated using an external `changelog` > > file as well as the commit history > > - When you opt-in, you will simply move the existing changelog to an external > > file `changelog`, which is placed in the dist-git repo and add the > > appropriate macro. > > > I assume you are aware about my PR: > > > https://pagure.io/packaging-committee/pull-request/942 > > > > - Upon building, the macro will generate the changelog using all the commits > > of the repo up to the last commit touching the `changelog` file. > > > I proposed, that the changelog file is either included in the repository > or it is not included (probably listed in .gitignore). So it is either > used as it is or if later, then it is generated. > > You propose mixture if I understand it correctly. I.e. the changelog > file is always present in the dist-git and it is always is used. But if > there are more recent commits without changelog modifications, they are > prepended to the changelog, but the changelog file itself stays > untouched. E.g. if my latest commit modifies the changelog, the > changelog as it is present in the repo will be used without any > modifications. > > I like it. It is opt-in, because I have to place some macro into .spec > file and it is even more or less bacward compatible, because the > automation kicks in only if I don't maintain the changelog manually. That is correct. I was aware of the PR to the FPC which actually contributed to this idea (figuring out the last commit that changed the `changelog` file is way easier than the last commit that changed %changelog in the spec file). So thanks for this! [About the release field] > I am not really sure about this. How do you envision this is going to be > implemented? Is there going to be "release" file, similarly to > changelog, which would help me to override this? Because, currently, it > seems that both methods are going to need a lot of information from the > build system. The first method using number of commits and number of builds, pull limited information from the build system (just: how many builds succeed before this one with this version and release?). The second method does rely heavily on the build system. > They will need to parse .spec file etc. I don't see this > to be able to handle even a bit more complex stuff like e.g. > https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_26 We've been trying to find something that fit the majority of the packages but we are well aware that there are and will always be some special snowflakes that will not be able to adhere to this. I'd be happy if this works makes life/packaging easier for 50% of our packages (I'd even probably be happy if it's 20%). Once we have the simple case out and we can test it, see how it behaves, what its limits are, we can start building on more complex cases, but I don't really believe on building the perfect solution in one go. Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
