Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Le dimanche 05 juillet 2020 à 23:36 +0200, Dan Čermák a écrit : > Nicolas Mailhot via devel writes: > > > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > > > Nicolas Mailhot via devel wrote: > > > > So if you want to push Fedora release logic to its ultimate > > > > conclusion, > > > > the thing that should be in charge of committing the new > > > > release/changelog build state to package history in git is > > > > bodhi, > > > > not > > > > koji. > > > > > > Why do build events need to be recorded in the Git history in the > > > first place? > > > > The changelog is built-in the rpm format. Therefore, it needs to > > exists > > at rpmbuild stage. Therefore, you need to record past changelog > > state > > so new builds are consistent with previous builds. > > The changelog should be consistent, but it needn't record every > single > build event. Otherwise OBS would not work at all: the build system > bumps > the release field automatically on each rebuild, but it does not > touch the changelog at all. Well just bumping the changelog by default, and letting the packager remove unecessary lines when he has the time to look at the changelog, is a much friendlier workflow than asking the packager to think about it on every single build, redoing builds when he forgot about it because redoing builds is the only way to get a new changelog included in the binary payload. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Nicolas Mailhot via devel writes: > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : >> Nicolas Mailhot via devel wrote: >> > So if you want to push Fedora release logic to its ultimate >> > conclusion, >> > the thing that should be in charge of committing the new >> > release/changelog build state to package history in git is bodhi, >> > not >> > koji. >> >> Why do build events need to be recorded in the Git history in the >> first place? > > The changelog is built-in the rpm format. Therefore, it needs to exists > at rpmbuild stage. Therefore, you need to record past changelog state > so new builds are consistent with previous builds. The changelog should be consistent, but it needn't record every single build event. Otherwise OBS would not work at all: the build system bumps the release field automatically on each rebuild, but it does not touch the changelog at all. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Le dimanche 05 juillet 2020 à 18:41 +0200, Nicolas Mailhot a écrit : > > While timestamping would remove the need to pass the last build info > to the next one it would also break all the workflows where several > rebuilds are done in parallel for separate needs, and the latest > rebuild is not necessarily the one you want to keep. (This is why git is not relying on timestamps to construct commit timelines, for example. A reliable timeline system knows what change occured before the next one.) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > Nicolas Mailhot via devel wrote: > > So if you want to push Fedora release logic to its ultimate > > conclusion, > > the thing that should be in charge of committing the new > > release/changelog build state to package history in git is bodhi, > > not > > koji. > > Why do build events need to be recorded in the Git history in the > first place? The changelog is built-in the rpm format. Therefore, it needs to exists at rpmbuild stage. Therefore, you need to record past changelog state so new builds are consistent with previous builds. You may argue that the existence of scms like git makes built-in changelogs irrelevant. People that have to debug problems in systems that mix packages sources will disagree – they have no wish to comb multiple external scms to find what was changed in a package set that breaks (hard to do when the thing that broke is networking for example). And, even if you removed completely the changelog from the rpm format, you’d still need to manage package releases. > So why is NEVR required to change when nothing in the package source > has changed? The NEVR is required to change because you need to publish a new package ID to clients, so clients know they have an update to deploy. That has nothing to do with koji limitations, it’s a requirement or the rpm update system, or pretty much any change management system for that matter. > It seems that several problems would just disappear if a rebuild > would generate a unique package ID without a Git commit. That’s exacly what the change does. > Here's an idea: We could mandate that Release must expand a macro > called buildtag. This macro would have a new value every time, > monotonically increasing. A timestamp seems easiest, but that should > bean implementation detail that could be changed without breaking > things. Because things are slightly more complex than you think they are, the counter is not just a timestamp, and there are two not one counter, but yes, again, that’s exacly what the change does. > (The build time is already stored in packages, and could > theoretically be used to tell builds apart, but that would require > changes to lots of tools I guess.) The build time by itself is not sufficient because you have branches, and scratch builds (which are basically abandonware branches) so parallel package history exists and a single monotonic timeline can not represent that. Nevertheless the last build time is useful (for changelog bumping, if nothing else) and is one of the things the change stores as past state (you could try to deduce it from other things, but why bother, a timestamp variable is cheap and easy to manipulate). > Mass rebuilds would no longer make any Git commits. They would just > take the latest version and submit it for building. Again, that’s basically what the change does. A build stores counters and date as they existed as the time of the build in one of the SRPM source files. The next build reads this file and computes a higher release. No external bump script involved. No spec file change required. The spec file can be left unchanged forever, the release info in there is just the last release someone made a change to the spec files, and everything autobumps from there. All you need is to pass the "last build" info from one build to another, which is done via importing the results of last build at the start of the new build. Since the import relies on SRPM content and nothing else you can even move the build chain from one buildsystem to another it will still work. While timestamping would remove the need to pass the last build info to the next one it would also break all the workflows where several rebuilds are done in parallel for separate needs, and the latest rebuild is not necessarily the one you want to keep. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org