Overview
Request 595500 superseded
submit new version 4.0.0
- Created by yast-team
- In state superseded
- Superseded by 595936
-
Open review for
repo-checker
- Open review for openSUSE:Factory:Staging:D
Request History
yast-team created request
submit new version 4.0.0
licensedigger accepted review
ok
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto added repo-checker as a reviewer
Please review build success
factory-auto accepted review
Check script succeeded
staging-bot added openSUSE:Factory:Staging:D as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:D"
staging-bot accepted review
Picked openSUSE:Factory:Staging:D
jengelh declined review
Looks like a missing changelog. If indeed there is no change, I would suggest to use the wiki-recommended syntax of 2nd-level bullet points and explicitly state there is no change:
```
- Update to 4.0.0
* No changes, just version bump [bnc...notaccessible]
```
jengelh declined request
Looks like a missing changelog. If indeed there is no change, I would suggest to use the wiki-recommended syntax of 2nd-level bullet points and explicitly state there is no change:
```
- Update to 4.0.0
* No changes, just version bump [bnc...notaccessible]
```
I don't understand the complain. 1) there is changelog 2) there is a bug reference in the log entry 3) it is explicitly written that it is about version bump in the entry 4) the patch was accepted as is into SLE already
SLE has no bearing on Factory. (In fact, I heard there was a factory-first policy). Anyway...
By current practice, factory submissions need to include some newsworthy upstream bullet points on version updates (or a short line on why not[1]). A good example is https://build.opensuse.org/request/show/592918 . In that submission, the submitter has mentioned upstream changes (asterisk), and decided to list spec changes too (using dash).
Submissions which lack this (e.g. 580885) get to have another go. In 595500 and others currently pending, this is missing similar to like in 580885.
[1] https://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29#What_goes_into_the_changelog 1st list number 2; 2nd list number 6.
while you are right, the changes files are not really nice from YaST. unfortunately this is how they do it all the time. So either the scripts used by yast need to be changed to change the format for all submission or we have to live with that. doesn't make sense to decline only selected submissions. they are automated :/
Unlike submissions, there is still a human component in review, so I'll save myself the time and just flag one to get the attention.
So if this is actually a script (wikipdea has a /bot$/ policy on usernames, hint, hint), then the script should be adjusted, or be published for it to be edited.
I am not objecting :-) you got the attention, the yast team will discuss their packaging style in the SLE15 post mortem. Now let's get that release out of the door.
well, the only thing i can say here is that the log is in the same format like last dozens of entries before. We (yast team) haven't been aware of any change in mandatory requirements for changelog entries so far. Also we (yast team) are upstream for these packages so I don't see a point in distinguishing various log entries. And as a last note we submit the same code into SLE codebase even OS and I'm not allowed to do any difference between these two bases.