Mailinglist Archive: opensuse-factory (443 mails)

< Previous Next >
Re: [opensuse-factory] Creating better user focused change info for Tumbleweed was please someone help with SR#711379


On 01/07/2019 21:46, Neal Gompa wrote:
On Mon, Jul 1, 2019 at 12:53 AM Simon Lees <sflees@xxxxxxx> wrote:



On 30/06/2019 22:50, Stefan Seyfried wrote:
Am 30.06.19 um 09:30 schrieb Simon Lees:

Maybe for packages I work on all the time, but when i'm not it'd still
be far quicker and easier for me to pull it out of the changelog on the
web ui,

The "Changelog in the web ui" shows the commit message.
I personally would be much less opposed putting lots of patchnames into
the commit message, but commit messages are not enforced *at all*.

Then your workflow would be

git-osc log => /patchname
git-osc show $VERSION_HASH

and you would immediately see where and when the patch was removed by
whom, including all context.

In case of a patch added it would just be

git-osc blame foo.spec => /patchname
git-osc show $VERSION_HASH

This would be the place they belong to: someone doing maintenance work
can look for them, search them (hopefully), and normal users can still
get clean package changelogs (in the .changes file).

Some of this comes back to a question of who should .changes files be
aimed at and I guess more broadly if we had a good vcs do we actually
need manually generated changelogs, with the right vcs these days we
could almost just ship a URL + revision.

In the context of SLE / Leap updates currently the changelog is not the
best place for end users to read about changes because the maintenance
team takes the changes entry and converts it into a _patchinfo, which
partly involves taking the .changes entry and making it more readable
for end users, this info is then presented nicely in tools like the yast
updater.

I think the big issue here is that since the invention of tumbleweed
.changes files have to cater for both users and developers so you trying
to write a neat tidy changelog for users to read which minimizes the
importants of specific patches which I as a developer maybe interested
in. Perhaps instead we should be looking at creating a different system
for developers to put the information that's important to users like we
currently have for _patchinfo files and generate a .changes / obs
history entry from that and other info automatically.

Potentially the hardest thing here is lining up patch filenames with
bugzilla / CVE entries, because generally the main reason I'd continue
to currently look in a changes file is because generally you can see
which patch in a change corresponds to which bug, it's very common to
take patches directly from upstream git repo's and as such they won't
contain the openSUSE specific bug number, currently the most reliable
way to find this info is by looking at the .changes file which should
list the patch name and bug number in the same line. This is something
that needs to be done by the packager but isn't info that is useful for
end users. Sometimes its easy to guess because some packagers put the
CVE or bug number in the patch name, or above the PatchX: line in the
spec file and sometimes the patch description will contain bsc# or boo#
but we have no constant rule here so its hard to automate. Maybe one
solution would be for osc to prompt you to enter a bugzilla number when
you add a .patch file, then the changes file could be generated from the
provided "user info" and other data. Maybe it could even be dropped, but
this would require "git-osc" or whatever it became being able to
accurately track changes across branches and projects where needed.


Wait a tick here... This looks like that at no point can packagers
submit proposed updates with the desired updateinfo content (what you
and OBS call patchinfo is known as updateinfo[1]).

Yep this is true, in a SLE context its always created by the maintenance team because they have further specific bugs to make patchinfo's more readable, for example all security bugs should be written in past tense and some others.

--

Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
References