<@james:fedora.im>
16:01:17
!startmeeting fpc
<@meetbot:fedora.im>
16:01:18
Meeting started at 2026-09-17 16:01:17 UTC
<@meetbot:fedora.im>
16:01:18
The Meeting name is 'fpc'
<@james:fedora.im>
16:01:20
!topic Roll Call
<@gotmax23:fedora.im>
16:01:31
!hi
<@zodbot:fedora.im>
16:01:32
gotmax23: Maxwell G (gotmax23) - he / him / his or they / them / theirs
<@tibbs:fedora.im>
16:01:35
Hello.
<@james:fedora.im>
16:02:00
Hey
<@decathorpe:fedora.im>
16:02:24
(I will not be able to participate today, sorry)
<@tibbs:fedora.im>
16:02:44
Sadly something got rescheduled and I have to leave in a few minutes.
<@james:fedora.im>
16:03:07
Wow, could be a short meeting then.
<@conan_kudo:matrix.org>
16:03:27
!hi
<@zodbot:fedora.im>
16:03:32
Conan Kudo 😌: Neal Gompa (ngompa) - he / him / his
<@james:fedora.im>
16:04:16
For people leaving ... make sure you at least look at: https://forge.fedoraproject.org/packaging/guidelines/issues/1569
<@conan_kudo:matrix.org>
16:04:21
(I'm only kind of here... have a lot to juggle today)
<@salimma:fedora.im>
16:04:33
!hi
<@zodbot:fedora.im>
16:04:34
Michel Lind ☘ UTC+1 😷: Michel Lind (salimma) - he / him / his
<@salimma:fedora.im>
16:04:42
I will be a few minutes late
<@carlwgeorge:fedora.im>
16:05:20
!hi
<@zodbot:fedora.im>
16:05:21
Carl George: Carl George (carlwgeorge) - he / him / his
<@salimma:fedora.im>
16:05:56
Sadly that issue doesn't come as a surprise
<@tibbs:fedora.im>
16:08:20
Yes it was bound to happen and has happened in the past, but not with something that's on nearly every machine.
<@carlwgeorge:fedora.im>
16:08:50
i know, let's ask fesco to yoink his provenpackager permissions
<@tibbs:fedora.im>
16:08:51
From our perspective, though, the question is whether there's anything we can do to make the proper way harder to miss.
<@conan_kudo:matrix.org>
16:08:52
well that ticket describes at least two separate problems
<@decathorpe:fedora.im>
16:09:58
ideally we'd have an algorithm / flowchart (or even just a lua macro) that did the snapshot versioning *for* you
<@gotmax23:fedora.im>
16:10:22
I started writing a macro for this yesterday and then realized none of it would work with norpm 🤷
<@james:fedora.im>
16:10:22
Hey, no contributing useful things when you aren't here ;)
<@conan_kudo:matrix.org>
16:10:34
back in the days of yore (a couple jobs back) I did actually write code for programmatically generating correct snapshot versions
<@salimma:fedora.im>
16:10:36
right, and separate from the forge macro (which still does not do the new style versioning guideline, I think?)
<@gotmax23:fedora.im>
16:10:36
I think we need to split out the two issues:
<@salimma:fedora.im>
16:10:42
forge macro can then just reuse this
<@gotmax23:fedora.im>
16:10:50
1) snapshot version being too complicated
<@gotmax23:fedora.im>
16:11:10
2) provenpackagers consistently not following Guidelines
<@gotmax23:fedora.im>
16:11:17
1 is something we should deal with
<@gotmax23:fedora.im>
16:11:22
2 can be sent to FESCo
<@conan_kudo:matrix.org>
16:11:27
I would argue that norpm not supporting rpmlua is a bug
<@james:fedora.im>
16:11:33
TBF ... I don't think it's complicated. My guess is that hadass just used whatever he knew worked, and didn't care what the std. was.
<@conan_kudo:matrix.org>
16:11:54
yes, hadess' versioning style is the same one debian and opensuse use
<@carlwgeorge:fedora.im>
16:12:14
in the past when this came up, i pointed out that having _six_ different snapshot formats (just for doing it in version, not counting the legacy way of doing it in release) is part of the problem, and we should reduce that number (ideally down to one)
<@salimma:fedora.im>
16:12:18
while not standard compliant... does it break something in practice?
<@carlwgeorge:fedora.im>
16:12:56
in this case, upgrade path
<@conan_kudo:matrix.org>
16:12:57
only if you don't consistently bump it
<@conan_kudo:matrix.org>
16:13:06
the problem here isn't that the format was wrong
<@conan_kudo:matrix.org>
16:13:19
but that the format used wasn't followed through
<@conan_kudo:matrix.org>
16:13:24
for subsequent updates
<@carlwgeorge:fedora.im>
16:13:47
i agree with gotmax23's assertion that the guidelines being too complicated contributes to people doing it wrong or ignoring them
<@james:fedora.im>
16:13:55
The point of our std. is that you only need to update the snapshot id and the release.
<@tibbs:fedora.im>
16:14:29
Bottom line is that if you go off and do your own thing, you have to make sure that it at least works and keeps working in future updates.
<@gotmax23:fedora.im>
16:14:37
The issue is that the second update didn't update the snapshot id
<@salimma:fedora.im>
16:14:37
right, just asking how urgent this is. I agree that a provenpackager blatantly disregarding standards is bad, but ...
<@salimma:fedora.im>
16:14:55
ah ok so the bad thing is the thing built lies about the version
<@tibbs:fedora.im>
16:14:57
The issue wasn't that they used a different method; that's annoying but it doesn't break things, really. But then the update did its own thing and sorted improperly.
<@conan_kudo:matrix.org>
16:15:21
right, hadess even gave an out with the `+1` thing
<@james:fedora.im>
16:15:22
I'm obviously fine with someone doing a macro to make it easier. But ... what Jason said.
<@conan_kudo:matrix.org>
16:15:30
that could have been bumped to `+2` and fixed it
<@salimma:fedora.im>
16:15:32
as in, the update will never be installed over what a user already has installed? fun
<@decathorpe:fedora.im>
16:15:43
(even if that `+` should have been `^`)
<@tibbs:fedora.im>
16:16:08
Anyway, sadly I really have to run but I'll look at the log when I get home in a few hours.
<@conan_kudo:matrix.org>
16:16:10
yup, but again, the format isn't broken in itself, it just wasn't followed through with the subsequent update
<@conan_kudo:matrix.org>
16:16:46
In case anyone is interested, here is my old code for generating snapshot versions, if gotmax23 wants to be inspired by it or something... https://gitlab.com/VelocityLimitless/Projects/obsctl/-/blob/main/obsctl/lib/spec.py?ref_type=heads
<@decathorpe:fedora.im>
16:16:48
(not followed through and test failures that pointed it out waived)
<@salimma:fedora.im>
16:17:16
so yeah, as Carl noted this is when following standards is important because the risk of accidents happening is worse with something people are not familiar with
<@salimma:fedora.im>
16:17:29
though really rpmdev-vercmp does exist...
<@gotmax23:fedora.im>
16:17:37
This is why I want to have a macro to calculate the snapshot properly and mandate its use
<@salimma:fedora.im>
16:17:49
(maybe QA has a follow up - reject updates that are not sorting higher than the previously released update)
<@gotmax23:fedora.im>
16:17:53
but we can't do that since lua is getting banned in Version
<@gotmax23:fedora.im>
16:18:08
and I want to have proper error handling and readable code for the macro
<@conan_kudo:matrix.org>
16:18:10
who decided that?
<@conan_kudo:matrix.org>
16:18:14
when did we do that?
<@salimma:fedora.im>
16:18:17
lua getting banned in version - details about that?
<@gotmax23:fedora.im>
16:18:32
nobody decided it, but I believe RHEL and ELN already run rpmautospec with norpm parsing
<@gotmax23:fedora.im>
16:18:39
and I was told they'd like to propose it for Fedora
<@decathorpe:fedora.im>
16:18:49
I'm pretty sure we procrastinated on that old ticket because we didn't want to ban lua in Version :D
<@conan_kudo:matrix.org>
16:18:51
yeah, no
<@conan_kudo:matrix.org>
16:19:07
that is an unreasonable ask
<@gotmax23:fedora.im>
16:19:23
this is something we need to figure out, since I think it would break ELN builds also
<@conan_kudo:matrix.org>
16:19:26
lua is the actual native scripting language of rpm, everything _else_ is subshelled stuff
<@gotmax23:fedora.im>
16:19:33
they've already flipped the norpm rpmautospec switch afaik
<@carlwgeorge:fedora.im>
16:19:44
and follow on effects for epel too
<@gotmax23:fedora.im>
16:19:46
well, %() is banned too :)
<@salimma:fedora.im>
16:19:49
so rpmautospec went from being brittle to just having an even worse replacement?
<@salimma:fedora.im>
16:19:51
amazing
<@conan_kudo:matrix.org>
16:20:05
it is actually more dangerous to make people shell out for stuff
<@gotmax23:fedora.im>
16:20:32
yes, but they want to ban *both*
<@james:fedora.im>
16:20:36
Stephen Gallagher: Not sure if you want to enter this flamewar ;)
<@salimma:fedora.im>
16:21:07
I... really don't understand what's the point of FRCL if this sort of things happen under the radar
<@conan_kudo:matrix.org>
16:21:09
yeah, that's pretty much not acceptable
<@decathorpe:fedora.im>
16:21:20
I'm pretty sure the only sane solution is Neal's WIP buildnumber thing :P
<@gotmax23:fedora.im>
16:21:38
https://github.com/fedora-eln/eln/issues/611
<@conan_kudo:matrix.org>
16:22:05
ugh
<@conan_kudo:matrix.org>
16:22:16
jfc on a bloody stick
<@conan_kudo:matrix.org>
16:23:36
I wonder if this is going to cause even more problems when we move to specparts and declarative builds
<@conan_kudo:matrix.org>
16:24:06
as we delete more things and rely more on macro engine based helpers, these "norpm" approaches are going to break
<@james:fedora.im>
16:25:08
!topic Open Floor
<@james:fedora.im>
16:25:12
A bit late, but eh
<@salimma:fedora.im>
16:25:14
if RHEL 11 goes ahead with it and it blows up. realistically is the pressure then more that we have to adopt it and fix it, or that they back out ?
<@carlwgeorge:fedora.im>
16:25:29
regardless of whether lua is allowed or not, i think lua for snapshots is overkill. you can define commit and shortcommit macros, and then use them in version, source, and autosetup.
<@conan_kudo:matrix.org>
16:25:32
it's a coin toss
<@salimma:fedora.im>
16:26:02
Carl Georgeyeah but we still need to be able to use that in the version string
<@james:fedora.im>
16:26:13
Also "someone just spends a bit changing rhel when it branches" as the third side of that coin.
<@gotmax23:fedora.im>
16:26:19
We could define a norpm-compatible macro to get shortcommit from first 7 of commit
<@carlwgeorge:fedora.im>
16:26:33
`Version: 5.0.0~^1.%{shortcommit}`
<@carlwgeorge:fedora.im>
16:26:33
<@carlwgeorge:fedora.im>
16:26:33
no lua needed
<@gotmax23:fedora.im>
16:26:44
But I wanted something that takes date, commit, scm, and baseversion and validates and combines them
<@gotmax23:fedora.im>
16:26:48
overkill, maybe
<@conan_kudo:matrix.org>
16:26:51
they apparently support `%sub` in norpm
<@decathorpe:fedora.im>
16:26:56
I think the gsub lua function is reimplemented in norpm so that should work
<@gotmax23:fedora.im>
16:27:09
but having people construct it manually isn't going great either
<@salimma:fedora.im>
16:27:10
may I say that name is terrible
<@salimma:fedora.im>
16:27:23
'norpm' to me sounds like 'hey let's replace everything with Dockerfiles'
<@conan_kudo:matrix.org>
16:27:44
it's the latest in a long line of rpm spec parsing reimplementations
<@gotmax23:fedora.im>
16:27:53
it's just a limited Python-based RPM parser, not that crazy
<@carlwgeorge:fedora.im>
16:27:54
right, but that's becomes less useful if we standarize on `<number>.<revision>` snap format and don't allow the rest
<@conan_kudo:matrix.org>
16:27:57
I'm guilty of one at least, but not for rpm based distros :P
<@conan_kudo:matrix.org>
16:29:29
supporting rpmlua shouldn't even be that difficult then, it's just regular lua with a couple of extra lua modules
<@james:fedora.im>
16:29:32
Yeh, one maybe useful thing we could get out of this is if we just say "it's too complicated to have N different snap formats, so everyone use this one"
<@james:fedora.im>
16:30:05
Everyone will probably ignore it to start, but maybe we can change over time.
<@conan_kudo:matrix.org>
16:30:40
the thing is, we are going to keep hitting this problem over and over in other places if we let people think it's okay to use parsers that don't support the full range of the spec format
<@salimma:fedora.im>
16:30:53
we need a Fedora Janitor project like Debian's
<@salimma:fedora.im>
16:31:10
a lot of these unsexy cleanup things should be automated as much as possible and hosted somewhere visible
<@james:fedora.im>
16:31:53
You have any ideas how we'd get that?
<@gotmax23:fedora.im>
16:32:35
does someone want to propose a Guidelines PR to codify one of the current snapshot Version formats and make the rest "legacy"?
<@carlwgeorge:fedora.im>
16:32:46
`Version: 1.0.0^1.%{shortcommit}`
<@carlwgeorge:fedora.im>
16:32:46
<@carlwgeorge:fedora.im>
16:32:46
no lua needed
<@salimma:fedora.im>
16:33:20
no, and full disclosure I don't have the bandwith to do anything like that
<@conan_kudo:matrix.org>
16:33:35
I could do that
<@carlwgeorge:fedora.im>
16:33:55
i've had a todo item forever to make some improvements to the snapshot guidelines, i could also do it
<@james:fedora.im>
16:34:07
Sold!
<@gotmax23:fedora.im>
16:34:10
We have six(!) in https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots
<@carlwgeorge:fedora.im>
16:34:14
i can get with neal to talk about this after the meeting
<@gotmax23:fedora.im>
16:34:16
which seems like a lot :)
<@gotmax23:fedora.im>
16:34:26
thank you
<@conan_kudo:matrix.org>
16:34:31
full disclosure, I also want to also mark all the snapshot in release stuff as legacy and undesirable
<@carlwgeorge:fedora.im>
16:34:39
iirc, it used to be 4, and neal added 2 more last time it was edited 😛
<@conan_kudo:matrix.org>
16:34:40
nobody should be doing that anymore anywhere
<@gotmax23:fedora.im>
16:34:54
I think that's already the case?
<@conan_kudo:matrix.org>
16:35:01
anyone doing that still needs a finger wag
<@salimma:fedora.im>
16:35:02
yes please
<@gotmax23:fedora.im>
16:35:09
"deprecated, but may be used"
<@salimma:fedora.im>
16:35:13
forge macros still do that by default and it's wrong
<@james:fedora.im>
16:35:16
You remember how bleeding edge Fedora is, right?
<@gotmax23:fedora.im>
16:35:19
eh, I guess that could be made stricter
<@salimma:fedora.im>
16:35:26
(and it's so hard to figure out how to undo it, I normally just give up on forge macros)
<@gotmax23:fedora.im>
16:35:53
the forge macros implemented a solution, but then it turned out it breaks norpm
<@gotmax23:fedora.im>
16:35:58
so then we're in a loop
<@conan_kudo:matrix.org>
16:36:04
I've gotten good at deleting forge macros from packages :P
<@gotmax23:fedora.im>
16:36:08
and I'd honestly like to get rid of them at this point anyways
<@carlwgeorge:fedora.im>
16:36:18
not opposed to banning snap in release stuff, but could we just remove that part and have that effectively be the ban?
<@gotmax23:fedora.im>
16:36:39
it would be good to see how many packages still use it
<@conan_kudo:matrix.org>
16:36:42
I would replace it with a statement that snapshot in release is no longer permitted
<@gotmax23:fedora.im>
16:36:58
if it's still a lot, removing it completely could add confusion
<@carlwgeorge:fedora.im>
16:36:59
like have the guidelines say "here is the one right way to do this, anything else that used to be here is not allowed going forward and should be ported to this standard"
<@conan_kudo:matrix.org>
16:37:05
we have no active RHEL or Fedora releases that require it, so it can be otherwise dropped
<@gotmax23:fedora.im>
16:37:41
the forge macros still default to it :(
<@carlwgeorge:fedora.im>
16:37:58
if it comes up as in demand for epel stuff still on the legacy format, we have a section in the epel docs for things no longer relevant to fedora
<@carlwgeorge:fedora.im>
16:38:42
we could also set it up like python has, with a note:
<@carlwgeorge:fedora.im>
16:38:42
<@carlwgeorge:fedora.im>
16:38:42
> These guidelines were replaced by a newer version.
<@carlwgeorge:fedora.im>
16:38:42
>
<@carlwgeorge:fedora.im>
16:38:42
> They exist as a historical reference for packages that don’t follow the new guidelines yet.
<@gotmax23:fedora.im>
16:38:53
let's do that
<@carlwgeorge:fedora.im>
16:38:54
we could also set it up like python has, a separate page with a note:
<@carlwgeorge:fedora.im>
16:38:54
<@carlwgeorge:fedora.im>
16:38:54
> These guidelines were replaced by a newer version.
<@carlwgeorge:fedora.im>
16:38:54
>
<@carlwgeorge:fedora.im>
16:38:54
> They exist as a historical reference for packages that don’t follow the new guidelines yet.
<@james:fedora.im>
16:38:58
I think the way is to have the "how to version a snapshot" say this is the only way to do it, and it has the snapshot in the version.
<@carlwgeorge:fedora.im>
16:39:47
the last time i tried to work on this, i tried to rewrite the entire versioning page, and i bit off more than i could chew and didn't finish it
<@conan_kudo:matrix.org>
16:40:02
I think the first stage we can all agree on is dropping snapshot-in-release
<@conan_kudo:matrix.org>
16:40:07
that we should do absolutely first
<@carlwgeorge:fedora.im>
16:40:36
by dropping, you mean moving the "Traditional versioning with part of the upstream version information in the Release field" section into a separate page with a notice?
<@conan_kudo:matrix.org>
16:40:42
yes
<@conan_kudo:matrix.org>
16:40:58
similar to what we did with the old Python stuff
<@carlwgeorge:fedora.im>
16:41:02
yeah that alone will cut the doc down ~40%
<@gotmax23:fedora.im>
16:41:32
it's confusing that something nobody should look at takes up 6 lines in the TOC also :(
<@gotmax23:fedora.im>
16:41:38
so please split it out
<@gotmax23:fedora.im>
16:41:51
it's confusing that something nobody should look at takes up 7 lines in the TOC also :(
<@conan_kudo:matrix.org>
16:41:58
I can absolutely do that with glee
<@carlwgeorge:fedora.im>
16:42:25
i almost hate to ask, but which of the six snap in version formats are you wanting to make the one to rule them all?
<@gotmax23:fedora.im>
16:42:50
I still don't understand the tilde + carrot combination
<@james:fedora.im>
16:42:56
That seems like a you and Conan Kudo 😌 problem.
<@gotmax23:fedora.im>
16:42:59
and I guess we need one for pre-releases and one for post-releases maybe
<@carlwgeorge:fedora.im>
16:43:08
```
<@carlwgeorge:fedora.im>
16:43:08
<date>.<revision>
<@carlwgeorge:fedora.im>
16:43:08
<date><scm><revision>
<@carlwgeorge:fedora.im>
16:43:08
<number>.<revision>
<@carlwgeorge:fedora.im>
16:43:08
<number>.<scm><revision>
<@carlwgeorge:fedora.im>
16:43:08
<scm><date>.<revision>
<@carlwgeorge:fedora.im>
16:43:08
<scm><number>.<revision>
<@carlwgeorge:fedora.im>
16:43:08
```
<@conan_kudo:matrix.org>
16:43:23
`<scm><date>.<revision>`
<@carlwgeorge:fedora.im>
16:43:29
indeed, we disagreed on this part before 😁
<@salimma:fedora.im>
16:44:04
I almost always use <date><scm><revision> but ideally I want a nice separator between the fields
<@james:fedora.im>
16:44:08
I'm dubious if keeping scm in there is helpful.
<@salimma:fedora.im>
16:44:09
damn it markdown
<@salimma:fedora.im>
16:44:14
date scm revision
<@carlwgeorge:fedora.im>
16:44:24
date is problematic, packagers don't agree if that is the author date, commit date, or the date you grabbed the snapshot
<@gotmax23:fedora.im>
16:44:35
I would like to allow for something that could support sorting multiple commits in one day (e.g., for upstream CI purposes)
<@salimma:fedora.im>
16:44:43
we should specify it is the commit date, I think?
<@conan_kudo:matrix.org>
16:44:48
yes
<@gotmax23:fedora.im>
16:44:50
date should be author date or committer date
<@carlwgeorge:fedora.im>
16:44:52
that's the other big concern with date
<@salimma:fedora.im>
16:44:58
it's about when that code was committed ... ok authored date might make sense too
<@salimma:fedora.im>
16:45:06
I just take "whatever date github shows" normally
<@conan_kudo:matrix.org>
16:45:15
commit date is always monotonically increasing
<@churchyard:fedora.im>
16:45:19
hi. we cannot outright ban snapshot in release, because without a version (or epoch) bump, you cannot migrate to a snapshot in version (if it's a pre-release snapshot)
<@salimma:fedora.im>
16:45:28
well as gotmax said if you have two commits that day
<@carlwgeorge:fedora.im>
16:45:39
epochs are fine for this imo
<@salimma:fedora.im>
16:45:41
the hash is not monotonically increasing so ... you might get in trouble
<@conan_kudo:matrix.org>
16:45:43
you can increase the precision if you really want to
<@gotmax23:fedora.im>
16:46:05
What about `0~<snapshot stuff>`?
<@gotmax23:fedora.im>
16:46:22
does that no sort before 0.1.0 or such?
<@carlwgeorge:fedora.im>
16:46:22
in a way that will consistently do a clean upgrade path? i have doubts
<@conan_kudo:matrix.org>
16:46:26
eh?
<@gotmax23:fedora.im>
16:46:30
does that not sort before 0.1.0 or such?
<@churchyard:fedora.im>
16:46:39
0~<snapshot stuff> is forever lower than 0-<snapshot stuff>
<@salimma:fedora.im>
16:46:43
yyyymmdd with optional hh at the back (provided that sorts above just yyyymmdd)
<@conan_kudo:matrix.org>
16:47:03
yep it makes the number bigger, so it always wins
<@conan_kudo:matrix.org>
16:47:50
I have done yyyymmddhhmm before and that sorts above yyyymmdd
<@churchyard:fedora.im>
16:47:50
What I mean is that if you currently have VERSION-<snapshot stuff> you cannot go to VERSION~<snapshot stuff> until VERSION is bumped
<@carlwgeorge:fedora.im>
16:47:54
i've thought a lot about this and i think the best format is `<number>.<revision>`.
<@carlwgeorge:fedora.im>
16:47:54
<@carlwgeorge:fedora.im>
16:47:54
* simple and short
<@carlwgeorge:fedora.im>
16:47:54
* allows multiple snapshots in a day
<@carlwgeorge:fedora.im>
16:47:54
* consistent upgrade path that is nearly impossible to screw up
<@churchyard:fedora.im>
16:48:07
So, we can ban it, with grantfathering exceptions to exisitng packages until their version is bumped.
<@decathorpe:fedora.im>
16:48:11
yeah I'm not sure the date is *that* useful ...
<@churchyard:fedora.im>
16:48:25
the date is not useful
<@carlwgeorge:fedora.im>
16:48:47
unless later a packager switches back to fewer digits thinking it's actually evaluated as a date when it's actually an integer
<@conan_kudo:matrix.org>
16:48:49
if it's commit date, I think it is useful, since it tells the age of the snapshotted code
<@churchyard:fedora.im>
16:49:05
<number>.<revision> is OK as the only option. do we allow <revision> for systems that numper revisions incrementally? or we want one format only even then?
<@conan_kudo:matrix.org>
16:49:13
if it is any other date, it is not useful
<@james:fedora.im>
16:49:36
Ugh, yeh.
<@churchyard:fedora.im>
16:49:37
IIRC it used to be "date of this being packaged" which was nuts
<@conan_kudo:matrix.org>
16:49:42
way back in the olden times, it was supposed to be the date you downloaded the code
<@conan_kudo:matrix.org>
16:49:46
which is stupid
<@churchyard:fedora.im>
16:50:13
\<number>.\<revision> is OK as the only option. do we allow \<revision> for systems that number revisions incrementally? or we want one format only even then?
<@carlwgeorge:fedora.im>
16:50:47
date and scm are not useful in my opinion. for snapshots the version primarily exists for sorting upgrades, not for communicating additional info.
<@churchyard:fedora.im>
16:50:50
I also find <scm><revision> a tad stupid, as the scm blends into the hash
<@conan_kudo:matrix.org>
16:50:53
and historically `<number>` is number of revisions from the tagged version it is on top of
<@conan_kudo:matrix.org>
16:51:21
which is why we had things like yum-3.4.3-1.git522
<@conan_kudo:matrix.org>
16:51:28
522 commits from git on top of v3.4.3
<@gotmax23:fedora.im>
16:51:55
I don't care about having `git` in there if there's something obv representing a git hash. But I think having no date and only a meaningless sorting number in the package metadata is not super helpful
<@carlwgeorge:fedora.im>
16:52:13
it's not meant to be helpful, it's meant to sort
<@gotmax23:fedora.im>
16:52:21
I know it's meant to sort
<@conan_kudo:matrix.org>
16:52:24
it's meant to be both
<@carlwgeorge:fedora.im>
16:52:33
anyone that cares about that detail is fully equipped to find that based on the url and commit
<@churchyard:fedora.im>
16:52:36
(I gotta go. thanks for trying to simplify this)
<@gotmax23:fedora.im>
16:52:41
I mean from a user perspective, it doesn't convey anything
<@conan_kudo:matrix.org>
16:52:42
the three major VCSes in use all use similar hashing functions, so shorthash alone tells you nothing
<@conan_kudo:matrix.org>
16:53:06
*DVCSes
<@james:fedora.im>
16:53:15
Why is it useful to know if upstream uses git or bzr?
<@carlwgeorge:fedora.im>
16:54:19
i don't recall that, but i have seen an upstream sort of do that before for their main version (commits since init). since the guidelines don't specify the simplest interpretation (which i follow) is the first snapshot you package is 1, the next snapshot you package is 2, etc.
<@carlwgeorge:fedora.im>
16:54:33
i don't recall that, but i have seen an upstream sort of do that before for their main version (commits since init). since the guidelines don't specify, the simplest interpretation (which i follow) is the first snapshot you package is 1, the next snapshot you package is 2, etc.
<@carlwgeorge:fedora.im>
16:55:16
seems like this convo is not over but the meeting almost is, should we take this to an issue?
<@conan_kudo:matrix.org>
16:55:22
probably
<@conan_kudo:matrix.org>
16:55:31
also I need food
<@carlwgeorge:fedora.im>
16:55:36
food is good
<@conan_kudo:matrix.org>
16:55:37
so we should call it here
<@gotmax23:fedora.im>
16:55:57
!action migrate legacy snapshot Release guidelines to separate page
<@salimma:fedora.im>
16:55:59
wait is anyone owning a follow up?
<@carlwgeorge:fedora.im>
16:55:59
i can file that and try to summarize the problem
<@james:fedora.im>
16:56:01
Yeh, I figure Carl George and Conan Kudo 😌 can talk about it a bunch and then propose the PR which simplifies everything?
<@conan_kudo:matrix.org>
16:56:05
!action Neal make a PR to clean out snapshot-in-release from the guidelines
<@conan_kudo:matrix.org>
16:56:24
let's first get snapshot-in-release dead
<@conan_kudo:matrix.org>
16:56:27
then we'll proceed from there
<@james:fedora.im>
16:56:52
But ... removing that is your carrot to do the other bits ;)
<@conan_kudo:matrix.org>
16:57:01
lol
<@gotmax23:fedora.im>
16:57:58
it sounds like we have a plan here now then?
<@conan_kudo:matrix.org>
16:58:30
yes
<@james:fedora.im>
16:58:33
Yeh, I guess I'll do some kind of "offical" comment today summarizing things. Unless someone else wants to volunteer?
<@gotmax23:fedora.im>
16:58:58
!action Neal and Carl to file separate issue to discuss additional snapshot-in-Version guidelines improvements
<@gotmax23:fedora.im>
16:59:36
I can take a look at a comment if you'd like, but I probably don't want to write it :)
<@james:fedora.im>
16:59:59
I meant to bring it up earlier ... but I also thought about allow some QA tests to only be allowed to be waived by QA people. Specifically the version < prev-version wrt this.
<@gotmax23:fedora.im>
17:00:46
My response would usually be that we should trust provenpackagers at least to have discretion on this, but meh :(
<@gotmax23:fedora.im>
17:01:01
There is a wider FESCo discussion about CI testing and making new tests required/gating
<@gotmax23:fedora.im>
17:01:13
This is the kind of thing that should be in the required/gating list, definitely
<@james:fedora.im>
17:01:19
Yeh
<@james:fedora.im>
17:01:54
Anyway ... I'll close the meeting. Carl George and Conan Kudo 😌 you guys have fun!
<@james:fedora.im>
17:02:02
!endmeeting