8:08 a.m.
Questionnaire right at the beginning, so if you tl;dr, you don't miss it:
https://forms.gle/Jgr13vtRkiUwLb6W6
This is no change proposal but rather a result of my long-term curiosity
around the $Subject problem. I hope I marked the results public so the
results are visible to anyone.
------------------
ATM, I know of at least those serious attempts to "automatize" the
%changelog maintenance and Release auto-bumping: [1, 2 and 3].
All those proposals are pretty complicated (I know, this is POV
statement), but some of them require significant changes in build systems
(like allowing the build system to back-push the generated stuff, building
the code variant which is not yet committed, so security problems, etc.).
It's not easy to decide the preferred variant... :-) But let me feed
the xkcd 927 :-) .... here is another. Call it e.g. the "Trivial" (or
compromise) variant.
Release tag problem/proposal
============================
Let's stop requiring Release bumps for each build. And let's put an
additional tag into Release, like proposed in [4]:
"Release: 1%{?dist}%{?buildtag}"
... and let the build-system to put there an artificial (but increasing for
subsequent build IDs) value.
Or alternatively, teach the build-system to enhance
%dist in a similar fashion, as suggested in [5].
The %changelog problem
======================
IMO, all the burnouts and wasted time around %changelog is caused by those
things:
a) we misinterpret what git-log is for, and what %chagnelog is for, but
b) we are still forced to properly maintain the %changelog, and
c) we have to duplicate %changelog in Bodhi
Simply put, IMO, there's no easy way to transform git-log to %changelog,
because those logs have different audiences (package users, vs. package
maintainers).
As I claimed somewhere before, as opt-in, I really don't see any problem
in allowing - as opt-in - any kind of the proposed automation. Even all
of them. ... so the questionnaire allows us to vote for (or against) all of
them.
But any such automation isn't for free ... people do typos in changelog,
and tend to fix them quickly by follow-up commits. Fixing changelog is
now a matter of just another commit, but with the automation - we have to
have proper syntax/semantics for fixes (and fixes for fixes), have some
commit filtering mechanisms, etc. And maintainers need to understand
them.. Take a look at GNU's gitlog-to-changelog, and example of use [6]
(fwiw, none of [1,2,3] attempted to re-use that logic).
Bringing in the automation into our processes will either (a) require a
**lot more pedantic maintainers** (even though we don't want to complicate
our life) or (b) mean a decrease of quality of %changelog(s). The (a) is
OK, as long as people opt-in. We have to admit that there's (b).
Is it acceptable in the Fedora community to relax the rules around %changelog,
and decrease its quality (a bit, or a lot)? Do we think that %changelog is no
more worth the all manual trouble? If we tend to answer yes, maybe we should
rather go with something trivial as this:
%changelog
* This package doesn't provide changelog metadata, check it online
https://src.fedoraproject.org/rpms/<name>/commits/<last_commit>
Such %changelog has a very similar level of quality as all the generated
approaches, and we don't have to complicate our lives (or buildsystem).
Alternatively, we can teach build systems to upload the git-log file
somewhere, or even extremely drop the changelog entirely (and only
reference the upstream changelog in %doc payload).
Side question: Is it really useful to put "Rebuilt for
https://fedoraproject.org/wiki/Fedora_XX_Mass_Rebuild" into changelogs?
[1] https://github.com/rpm-software-management/mock/pull/526
[2]
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_mac...
[3] https://docs.pagure.org/Fedora-Infra.rpmautospec/index.html
[4]
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahoste...
[5]
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahoste...
[6] https://git.savannah.gnu.org/cgit/libtool.git/tree/Makefile.am#n553
Ideas?
Pavel
10:04 a.m.
Pavel Raiskup wrote:
Questionnaire right at the beginning, so if you tl;dr, you don't
miss it:
https://forms.gle/Jgr13vtRkiUwLb6W6
The questionnaire itself is short, but understanding all the proposals
is considerable work. That's where TL;DR will happen.
Let's stop requiring Release bumps for each build. And let's
put an
additional tag into Release, like proposed in [4]:
"Release: 1%{?dist}%{?buildtag}"
... and let the build-system to put there an artificial (but increasing for
subsequent build IDs) value.
I am of course in favor of this, as I've already suggested it myself.
Or alternatively, teach the build-system to enhance
%dist in a similar fashion, as suggested in [5].
That would also work technically, although it would turn the name
"dist" into a misnomer.
%changelog
* This package doesn't provide changelog metadata, check it online
https://src.fedoraproject.org/rpms/<name>/commits/<last_commit>
To the extent that users read changelogs at all, I think they would be
more interested in the upstream changelog than in the Fedora Git
changelog.
Side question: Is it really useful to put "Rebuilt for
https://fedoraproject.org/wiki/Fedora_XX_Mass_Rebuild" into changelogs?
I don't see any use for those entries. There is already a build
timestamp in the package metadata.
Björn Persson
10:35 a.m.
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
Such %changelog has a very similar level of quality as all the
generated
approaches, and we don't have to complicate our lives (or buildsystem).
Alternatively, we can teach build systems to upload the git-log file
somewhere, or even extremely drop the changelog entirely (and only
reference the upstream changelog in %doc payload).
Yeah, I like automatically including the git changelog as %doc at somewhere
like `/usr/share/doc/rpm-changelogs/$PACKAGENAME`. As a sysadmin in the
past, I've found it handy to be able to reference this directly on the
system.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:51 a.m.
Once upon a time, Matthew Miller <mattdm(a)fedoraproject.org> said:
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> Such %changelog has a very similar level of quality as all the generated
> approaches, and we don't have to complicate our lives (or buildsystem).
> Alternatively, we can teach build systems to upload the git-log file
> somewhere, or even extremely drop the changelog entirely (and only
> reference the upstream changelog in %doc payload).
Yeah, I like automatically including the git changelog as %doc at somewhere
like `/usr/share/doc/rpm-changelogs/$PACKAGENAME`. As a sysadmin in the
past, I've found it handy to be able to reference this directly on the
system.
That makes it extra steps to see changelogs on a not-installed package.
I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog
foo"
(for example, to see what is changed since my installed version).
Converting to an installed file means I would have to extract the RPM
(possibly after manually downloading) and find it under a different
directory for every RPM - much less convenient.
--
Chris Adams <linux(a)cmadams.net>
11:53 a.m.
On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
That makes it extra steps to see changelogs on a not-installed
package.
I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog
foo"
(for example, to see what is changed since my installed version).
Converting to an installed file means I would have to extract the RPM
(possibly after manually downloading) and find it under a different
directory for every RPM - much less convenient.
A dnf plugin could be made which shows metadata like this from
src.fedoraproject.org or bodhi or some other source.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:57 a.m.
On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> That makes it extra steps to see changelogs on a not-installed package.
> I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog
foo"
> (for example, to see what is changed since my installed version).
> Converting to an installed file means I would have to extract the RPM
> (possibly after manually downloading) and find it under a different
> directory for every RPM - much less convenient.
A dnf plugin could be made which shows metadata like this from
src.fedoraproject.org or bodhi or some other source.
That's not helpful beyond Fedora, though. When it's forked into RHEL
or CentOS, that changelog history from Fedora is preserved today. RHEL
forks Fedora at the git level, so generated changelogs from Git will
still work, and since CentOS gets SRPM imports into its Dist-Git,
they'll be flattened into %changelog sections as appropriate. But if
we rely on a web service to get changelogs, we screw over that
particular transition path.
--
真実はいつも一つ！/ Always, there's only one truth!
2:25 p.m.
On Tue, Aug 25, 2020 at 12:57:34PM -0400, Neal Gompa wrote:
On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
>
> On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> > That makes it extra steps to see changelogs on a not-installed package.
> > I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf
changelog foo"
> > (for example, to see what is changed since my installed version).
> > Converting to an installed file means I would have to extract the RPM
> > (possibly after manually downloading) and find it under a different
> > directory for every RPM - much less convenient.
>
> A dnf plugin could be made which shows metadata like this from
> src.fedoraproject.org or bodhi or some other source.
>
That's not helpful beyond Fedora, though. When it's forked into RHEL
or CentOS, that changelog history from Fedora is preserved today. RHEL
forks Fedora at the git level, so generated changelogs from Git will
still work, and since CentOS gets SRPM imports into its Dist-Git,
they'll be flattened into %changelog sections as appropriate. But if
we rely on a web service to get changelogs, we screw over that
particular transition path.
Sure, but how often is that changelog:
"Updated to 10.0.1"
or
"Fixed typo"
I pretty much stopped reading changelogs a while back.
Looking at the upstream NEWS or announcement is better for releases, and
just looking at the git commits is better for isolating some change in
packaging.
kevin
2:42 p.m.
On Tue, Aug 25, 2020 at 3:26 PM kevin <kevin(a)scrye.com> wrote:
On Tue, Aug 25, 2020 at 12:57:34PM -0400, Neal Gompa wrote:
> On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller
> <mattdm(a)fedoraproject.org> wrote:
> >
> > On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> > > That makes it extra steps to see changelogs on a not-installed package.
> > > I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf
changelog foo"
> > > (for example, to see what is changed since my installed version).
> > > Converting to an installed file means I would have to extract the RPM
> > > (possibly after manually downloading) and find it under a different
> > > directory for every RPM - much less convenient.
> >
> > A dnf plugin could be made which shows metadata like this from
> > src.fedoraproject.org or bodhi or some other source.
> >
>
> That's not helpful beyond Fedora, though. When it's forked into RHEL
> or CentOS, that changelog history from Fedora is preserved today. RHEL
> forks Fedora at the git level, so generated changelogs from Git will
> still work, and since CentOS gets SRPM imports into its Dist-Git,
> they'll be flattened into %changelog sections as appropriate. But if
> we rely on a web service to get changelogs, we screw over that
> particular transition path.
Sure, but how often is that changelog:
"Updated to 10.0.1"
or
"Fixed typo"
I pretty much stopped reading changelogs a while back.
Looking at the upstream NEWS or announcement is better for releases, and
just looking at the git commits is better for isolating some change in
packaging.
I do the opposite. I almost never read upstream news or changelog
files. They just don't matter in most cases when I'm trying to figure
out problems. Those timelines in the packaging changelogs are a good
record of how the package itself has evolved, and sure, most of the
time it's just updating to a new version, but those checkpoints are
useful too.
And in the Fedora -> RHEL -> CentOS case, we do not have those
relationships with Git commits, so the changelog entries are the only
way to figure out packaging deltas and such.
--
真実はいつも一つ！/ Always, there's only one truth!
2:31 a.m.
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
Release tag problem/proposal
============================
Let's stop requiring Release bumps for each build. And let's put an
additional tag into Release, like proposed in [4]:
"Release: 1%{?dist}%{?buildtag}"
... and let the build-system to put there an artificial (but increasing for
subsequent build IDs) value.
Or alternatively, teach the build-system to enhance
%dist in a similar fashion, as suggested in [5].
With this we will loose the ability to map RPM version information to a
SPEC file without querying Koji for the dist-git commit. Currently,
looking at dist-git allows to quickly check if there is a release there
than on a system. Not sure how useful it is but sometimes when I looked
into FTBFS bugs it was helpful to see that the last build did not match
dist-git which indicated that the SRPM creation failed in koji. Then it
looks like the package was never tried to be built. With those changes
it seems that dist-git will look untouched after a mass-rebuild.
Also, what about other special cases when using 0.1 for the release to
indicate pre-releases or git IDs for snapshots. How would that look
like with your proposal?
Thanks
Till
6:53 a.m.
Till Maas wrote:
what about other special cases when using 0.1 for the release to
indicate pre-releases or git IDs for snapshots. How would that look
like with your proposal?
None of that needs to change just because a buildtag is appended.
Whenever the source code changes in any way, one or more of the current
parts of the Version and Release fields should be updated. For a
rebuild, when the source code hasn't changed, the spec wouldn't need to
change either, and only the buildtag would set the rebuilt package
apart from the previous one.
Björn Persson
3:45 a.m.
On 13.08.2020 15:08, Pavel Raiskup wrote:
"Release: 1%{?dist}%{?buildtag}"
I have a better solution - automatically bump Release on every official
build. Additional tags are not good.
%changelog
* This package doesn't provide changelog metadata, check it online
https://src.fedoraproject.org/rpms/<name>/commits/<last_commit>
+1 for this. Most of changelogs contains just "Updated to version X" and
can be safely removed.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:55 p.m.
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
Let's stop requiring Release bumps for each build. And let's
put an
additional tag into Release, like proposed in [4]:
"Release: 1%{?dist}%{?buildtag}"
Can I ask why this wouldn't be:
Release: 1%{?buildtag}%{?dist}
?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
4:05 a.m.
Richard W.M. Jones wrote:
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> Let's stop requiring Release bumps for each build. And let's put an
> additional tag into Release, like proposed in [4]:
>
> "Release: 1%{?dist}%{?buildtag}"
Can I ask why this wouldn't be:
Release: 1%{?buildtag}%{?dist}
?
Putting the buildtag after the disttag makes it possible to change how
the buildtag is generated in a future Fedora release without breaking
upgrade paths.
Björn Persson
3:57 a.m.
On 13. 08. 20 15:08, Pavel Raiskup wrote:
I hope I marked the results public so the
results are visible to anyone.
I could see the results when I've submitted the form, but I no longer know how
to get to them. Can you share the link please?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:02 a.m.
On Tuesday, August 18, 2020 10:57:32 AM CEST Miro Hrončok wrote:
On 13. 08. 20 15:08, Pavel Raiskup wrote:
> I hope I marked the results public so the
> results are visible to anyone.
I could see the results when I've submitted the form, but I no longer know how
to get to them. Can you share the link please?
https://docs.google.com/forms/d/e/1FAIpQLSc_QWWjEnbCKwlrosxt6CiwR37sDWO6m...
Pavel
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
3:46 a.m.
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
Questionnaire right at the beginning, so if you tl;dr, you don't
miss it:
https://forms.gle/Jgr13vtRkiUwLb6W6
This is no change proposal but rather a result of my long-term curiosity
around the $Subject problem. I hope I marked the results public so the
results are visible to anyone.
------------------
ATM, I know of at least those serious attempts to "automatize" the
%changelog maintenance and Release auto-bumping: [1, 2 and 3].
All those proposals are pretty complicated (I know, this is POV
statement), but some of them require significant changes in build systems
(like allowing the build system to back-push the generated stuff, building
the code variant which is not yet committed, so security problems, etc.).
It's not easy to decide the preferred variant... :-) But let me feed
the xkcd 927 :-) .... here is another. Call it e.g. the "Trivial" (or
compromise) variant.
Release tag problem/proposal
============================
Let's stop requiring Release bumps for each build. And let's put an
additional tag into Release, like proposed in [4]:
"Release: 1%{?dist}%{?buildtag}"
... and let the build-system to put there an artificial (but increasing for
subsequent build IDs) value.
When looking into rpmautospec this was one of the idea we thought about. There
are a few downsides to it that made us go in a different direction:
- Relies on the build system and cannot be emulated locally (without access to
it)
- Conflicts wit the minor release bump field of the versioning schema:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_mo...
IIRC the first one was the one that blocked this idea for us as it was mentioned
on the list that people want to be able to build their RPM locally as close as
possible from what the build system does.
The %changelog problem
======================
IMO, all the burnouts and wasted time around %changelog is caused by those
things:
a) we misinterpret what git-log is for, and what %chagnelog is for, but
b) we are still forced to properly maintain the %changelog, and
c) we have to duplicate %changelog in Bodhi
Well, the bodhi update description should likely be the one most different from
the other two.
[..]
If we tend to answer yes, maybe we should rather go with something
trivial as
this:
%changelog
* This package doesn't provide changelog metadata, check it online
https://src.fedoraproject.org/rpms/<name>/commits/<last_commit>
One of our requirement when we looked into this for rpmautospec was that the
changelog should be accessible on a machine without internet (think: network
stack is busted, I want to check what changed in the rpm of that stack).
So while tempting this wouldn't fit.
Pierre
3:54 a.m.
On Wed, Aug 19, 2020 at 10:46:48AM +0200, Pierre-Yves Chibon wrote:
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> Questionnaire right at the beginning, so if you tl;dr, you don't miss it:
>
> https://forms.gle/Jgr13vtRkiUwLb6W6
>
> This is no change proposal but rather a result of my long-term curiosity
> around the $Subject problem. I hope I marked the results public so the
> results are visible to anyone.
>
> ------------------
>
> ATM, I know of at least those serious attempts to "automatize" the
> %changelog maintenance and Release auto-bumping: [1, 2 and 3].
>
> All those proposals are pretty complicated (I know, this is POV
> statement), but some of them require significant changes in build systems
> (like allowing the build system to back-push the generated stuff, building
> the code variant which is not yet committed, so security problems, etc.).
>
> It's not easy to decide the preferred variant... :-) But let me feed
> the xkcd 927 :-) .... here is another. Call it e.g. the "Trivial" (or
> compromise) variant.
>
>
> Release tag problem/proposal
> ============================
>
> Let's stop requiring Release bumps for each build. And let's put an
> additional tag into Release, like proposed in [4]:
>
> "Release: 1%{?dist}%{?buildtag}"
>
> ... and let the build-system to put there an artificial (but increasing for
> subsequent build IDs) value.
When looking into rpmautospec this was one of the idea we thought about. There
are a few downsides to it that made us go in a different direction:
- Relies on the build system and cannot be emulated locally (without access to
it)
- Conflicts wit the minor release bump field of the versioning schema:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_mo...
IIRC the first one was the one that blocked this idea for us as it was mentioned
on the list that people want to be able to build their RPM locally as close as
possible from what the build system does.
> The %changelog problem
> ======================
>
> IMO, all the burnouts and wasted time around %changelog is caused by those
> things:
>
> a) we misinterpret what git-log is for, and what %chagnelog is for, but
> b) we are still forced to properly maintain the %changelog, and
> c) we have to duplicate %changelog in Bodhi
Well, the bodhi update description should likely be the one most different from
the other two.
[..]
> If we tend to answer yes, maybe we should rather go with something trivial as
> this:
>
> %changelog
> * This package doesn't provide changelog metadata, check it online
> https://src.fedoraproject.org/rpms/<name>/commits/<last_commit>
One of our requirement when we looked into this for rpmautospec was that the
changelog should be accessible on a machine without internet (think: network
stack is busted, I want to check what changed in the rpm of that stack).
In such cases it is often possible to just use another machine whose
networking stack isn't busted to view the link. Even if this means
using a smartphone.
I think the value of the %changelog for debugging problems on a host
is overstated in general though. In most cases I find the entries are
just too terse to be useful, especially when you have packages where
the only changelog info is "rebased to version x.y.z", with the actual
useful info being in the release notes provided by the upstream project.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:52 a.m.
On Wednesday, 19 August 2020 at 10:54, Daniel P. Berrangé wrote:
[...]
I think the value of the %changelog for debugging problems on a host
is overstated in general though. In most cases I find the entries are
just too terse to be useful, especially when you have packages where
the only changelog info is "rebased to version x.y.z", with the actual
useful info being in the release notes provided by the upstream
project.
That useful info is often included as ChangeLog or NEWS file in %doc
section of the RPM, so you often do have it locally.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
9:30 a.m.
On Wed, 2020-08-19 at 10:46 +0200, Pierre-Yves Chibon wrote:
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> Release tag problem/proposal
> ============================
>
> Let's stop requiring Release bumps for each build. And let's put
> an
> additional tag into Release, like proposed in [4]:
>
> "Release: 1%{?dist}%{?buildtag}"
>
> ... and let the build-system to put there an artificial (but
> increasing for
> subsequent build IDs) value.
When looking into rpmautospec this was one of the idea we thought
about. There
are a few downsides to it that made us go in a different direction:
- Relies on the build system and cannot be emulated locally (without
access to
it)
To be fair and considering that local builds with the rpmautospec macro
don't magically know about historical builds -- local or Koji -- this
scheme could be made to work locally in a similar way as ours: just
define the macro as %{nil} (or .1 or whatever) in redhat-rpm-config.
- Conflicts wit the minor release bump field of the versioning
schema:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_mo...
That's a more serious obstacle IMO. The way we overload the release
field in Fedora doesn't seem to work with many simple approaches.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
10:04 a.m.
On Wed, Aug 19, 2020 at 04:30:18PM +0200, Nils Philippsen wrote:
On Wed, 2020-08-19 at 10:46 +0200, Pierre-Yves Chibon wrote:
> On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> > Release tag problem/proposal
> > ============================
> >
> > Let's stop requiring Release bumps for each build. And let's put
> > an
> > additional tag into Release, like proposed in [4]:
> >
> > "Release: 1%{?dist}%{?buildtag}"
> >
> > ... and let the build-system to put there an artificial (but
> > increasing for
> > subsequent build IDs) value.
>
> When looking into rpmautospec this was one of the idea we thought
> about. There
> are a few downsides to it that made us go in a different direction:
>
> - Relies on the build system and cannot be emulated locally (without
> access to
> it)
To be fair and considering that local builds with the rpmautospec macro
don't magically know about historical builds -- local or Koji -- this
scheme could be made to work locally in a similar way as ours: just
define the macro as %{nil} (or .1 or whatever) in redhat-rpm-config.
Since the logic used by rpmautospec is stored in the git tags, you can
pre-process the spec file locally just like koji does, thus giving you the
possibility to build locally just like koji does.
This is what I had in mind with my comment. Does it make sense?
Pierre
10:34 a.m.
On Wed, 2020-08-19 at 17:04 +0200, Pierre-Yves Chibon wrote:
On Wed, Aug 19, 2020 at 04:30:18PM +0200, Nils Philippsen wrote:
> On Wed, 2020-08-19 at 10:46 +0200, Pierre-Yves Chibon wrote:
> > On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> > > Release tag problem/proposal
> > > ============================
> > >
> > > Let's stop requiring Release bumps for each build. And let's
> > > put
> > > an
> > > additional tag into Release, like proposed in [4]:
> > >
> > > "Release: 1%{?dist}%{?buildtag}"
> > >
> > > ... and let the build-system to put there an artificial (but
> > > increasing for
> > > subsequent build IDs) value.
> >
> > When looking into rpmautospec this was one of the idea we thought
> > about. There
> > are a few downsides to it that made us go in a different
> > direction:
> >
> > - Relies on the build system and cannot be emulated locally
> > (without
> > access to
> > it)
>
> To be fair and considering that local builds with the rpmautospec
> macro
> don't magically know about historical builds -- local or Koji --
> this
> scheme could be made to work locally in a similar way as ours: just
> define the macro as %{nil} (or .1 or whatever) in redhat-rpm-
> config.
Since the logic used by rpmautospec is stored in the git tags, you
can
pre-process the spec file locally just like koji does, thus giving
you the
possibility to build locally just like koji does.
This is what I had in mind with my comment. Does it make sense?
Ahh, it's one of those features we haven't gotten around to yet. I was
thinking of the rpmbuild case which has the release as "1%{?dist}", and
you probably thought of "fedpkg local". Yes, that makes sense.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
8:57 a.m.
Pierre-Yves Chibon wrote:
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> Let's stop requiring Release bumps for each build. And let's put an
> additional tag into Release, like proposed in [4]:
>
> "Release: 1%{?dist}%{?buildtag}"
>
> ... and let the build-system to put there an artificial (but increasing for
> subsequent build IDs) value.
When looking into rpmautospec this was one of the idea we thought about. There
are a few downsides to it that made us go in a different direction:
- Relies on the build system and cannot be emulated locally (without access to
it)
Using timestamps for buildtags would work across build systems, relying
only on the clock not being wildly off.
Using Copr build IDs and Koji task IDs, each build system would have
its own series of buildtags. Local Mock and plain RPMbuild could have
their own series too, using timestamps or something else.
The feature that was recently added to Copr generates buildtags that
begin with ".copr". Buildtags from Koji could begin with ".koji".
These
prefixes could be chosen so that a build from Koji takes priority over
one from Copr, and a local build takes priority over both of those. I
notice that "local" > "koji" > "copr". How convenient.
(A package being
moved from Fedora to Copr would then need a manual release bump, but I
can't think of a reason to do that if there's neither a new version nor
any change to the packaging.)
- Conflicts wit the minor release bump field of the versioning
schema:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_mo...
I think I see what you mean. If buildtags are purely numeric, then
inserting a small numeric minorbump before the buildtag where the field
was previously empty would cause the new build to compare as less than
the previous one:
$ rpmdev-vercmp 1-1.fc33.98765 1-1.fc33.1.98789
1-1.fc33.98765 > 1-1.fc33.1.98789
If, on the other hand, buildtags begin with a letter and minorbumps are
numeric, then a build with a minorbump would compare as greater:
$ rpmdev-vercmp 1-1.fc33.koji98765 1-1.fc33.1.koji98789
1-1.fc33.koji98765 < 1-1.fc33.1.koji98789
Another option is to have the minorbump field always present, with the
value 0 when not in use. Yet another option is to put the minorbump
after the buildtag. I'd say this is technically manageable, but there
is some risk that packagers would do minorbumps wrong by mistake.
Björn Persson
6:47 a.m.
Disclaimer: I'm part of the team who worked on rpmautospec, i.e. I'm
obviously biased and will view everything through that lens. ;)
On Thu, 2020-08-13 at 15:08 +0200, Pavel Raiskup wrote:
Release tag problem/proposal
============================
Let's stop requiring Release bumps for each build. And let's put an
additional tag into Release, like proposed in [4]:
"Release: 1%{?dist}%{?buildtag}"
We discussed something like this for rpmautospec but went with "more
complicated" because that lets us do two things:
- Give maintainers a parametrized macro which makes it easier to
package pre-/post-/snapshot-releases. This use case is one of the more
complicated ways to (ab)use the release field and I've time and again
seen it done wrongly. Getting it right in one place and absolving
maintainers from dealing with the complexity involved seemed like a
good thing to have.
- Take history, i.e. existing builds in the affected and other Fedora
releases, into account. For one, this allows us to ensure a clean
update path (AIUI, this is still required by the packaging guidelines)
about as good as manual maintenance would. For another, it makes opting
in easy: just put in the macro and you're done, no need to keep the
bumped release and remember to reset it when the next version bump
happens.
The %changelog problem
======================
...
Bringing in the automation into our processes will either (a)
require
a
**lot more pedantic maintainers** (even though we don't want to
complicate
our life) or (b) mean a decrease of quality of %changelog(s). The
(a) is
OK, as long as people opt-in. We have to admit that there's (b).
I disagree with both points.
In my experience, the %changelog contents are just a subset of what
ends up in the SCM commit log(*). Mistakes happen of course (some
mistakes shouldn't, e.g. wrongly formatted dates), but they can be
corrected after the fact, with or without automation.
Mind that -- beyond our original prototype -- we surely want a way to
let people directly flag a commit not to be used in the changelog, e.g.
for the "oops, forgot to upload the tarball" situations, where having
to let e.g. fedpkg update the external changelog file and edit that is
somewhat over the top.
My take is that whether or not mistakes get fixed largely depends on
how the individual maintainer feels, regardless of if the changelog is
manually or automatically maintained.
(*): If not, i.e. if the %changelog of your package is only spuriously
related to what's in git commit logs, then changelog automation won't
help you. One of the reasons why it's opt-in.
Is it acceptable in the Fedora community to relax the rules around
%changelog,
and decrease its quality (a bit, or a lot)? Do we think that
%changelog is no
more worth the all manual trouble? If we tend to answer yes, maybe
we should
rather go with something trivial as this:
%changelog
* This package doesn't provide changelog metadata, check it online
https://src.fedoraproject.org/rpms/<name>/commits/<last_commit>
Such %changelog has a very similar level of quality as all the
generated
approaches, and we don't have to complicate our lives (or
buildsystem).
Downside is, it can't be accessed offline _and_ you have to wade
through all the "fixed this and that mistake" cruft.
Alternatively, we can teach build systems to upload the git-log file
somewhere, or even extremely drop the changelog entirely (and only
reference the upstream changelog in %doc payload).
Not sure what you mean by "upstream changelog", if it's the one
upstream that doesn't (usually can't) cover packaging changes like
"split off bananas into its own subpackage", then I'm strictly against
it. That information is valuable.
Side question: Is it really useful to put "Rebuilt for
https://fedoraproject.org/wiki/Fedora_XX_Mass_Rebuild" into
changelogs?
Our idea was that these entries would go away with %changelog
automation, as mass rebuilds could simply build again from the HEAD of
the branch.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
1339
days inactive
1351
days old
22 comments
14 participants
participants (14)
-
Björn Persson -
Chris Adams -
Daniel P. Berrangé -
Dominik 'Rathann' Mierzejewski -
kevin -
Matthew Miller -
Miro Hrončok -
Neal Gompa -
Nils Philippsen -
Pavel Raiskup -
Pierre-Yves Chibon -
Richard W.M. Jones -
Till Maas -
Vitaly Zaitsev