Bug 522660 - more information in package change / project change / package updated requests
Summary: more information in package change / project change / package updated requests
Status: RESOLVED WONTFIX
Alias: None
Product: openSUSE.org
Classification: openSUSE
Component: Hermes (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal with 5 votes (vote)
Target Milestone: ---
Assignee: Christopher Hofmann
QA Contact: Adrian Schröter
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-16 12:06 UTC by Marcus Meissner
Modified: 2016-02-10 16:16 UTC (History)
4 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2009-07-16 12:06:12 UTC
We need more information in the package / project changed and updated request.

This is two parts:

- bs_srcserver needs to send more information to Hermes
- Hermes template needs to include this data.

Its probably possible to diff the XML before/after. (not text diff, but some other diff method).
Comment 1 Marcus Meissner 2009-07-16 12:07:16 UTC
i could send patches if you tell me where the VCS repo of the bsserver is ;)
Comment 2 Klaas Freitag 2009-07-16 12:11:17 UTC
SVN URL:
 https://forgesvn1.novell.com/svn/opensuse/trunk/buildservice/src/backend

Please bear in mind that just an xml diff might be fine for super geeks but not for normal users. Maybe we can come up with something more user friendly?

And check first with mls before patching.
Comment 3 Marcus Meissner 2009-07-16 12:15:00 UTC
i am not thinking of raw xml diffs, this will not be helpful I suspect.

more have the XML put into a good visual structure and diff that,
or even parse the XML before/after and generate a hand-made difference report.
Comment 4 Adrian Schröter 2009-08-07 08:43:08 UTC
This a regression and is quite time consuming for packagers -> High prio.
Comment 5 Marcus Meissner 2009-12-07 08:58:12 UTC
without this no "Normal" user, neither community nor SUSE employee can easily see
who changed what and when.

The security team requested this in July, it is still not done.

Adjust priority to match our requirements.
Comment 6 Klaas Freitag 2010-01-20 09:05:28 UTC
Please provide a diff without diffing tarballs for source change. 

Hermes can either
1. get the diff as a parameter provided through the BSHermes call in bs_srcserver
2. or call the API later to get the diff, for that an API call needs to be there
and old an new version numbers must be provided through parameters to BSHermes

Its up to you how we implement it. For me, option 1. would be more convenient. 
Since it is a GET request, the size of the diff would be limited to $GET_SIZE_LIMIT (64k?) however. Is that a problem if we diff without tars?
Comment 7 Stephan Kulow 2010-01-20 09:31:22 UTC
you can still get large diff if you patch large patches
Comment 8 Marcus Meissner 2010-04-23 21:18:58 UTC
still not done
Comment 9 Harald Mueller-Ney 2010-06-16 15:12:01 UTC
(In reply to comment #2)
> SVN URL:
>  https://forgesvn1.novell.com/svn/opensuse/trunk/buildservice/src/backend
> 
> Please bear in mind that just an xml diff might be fine for super geeks but not
> for normal users. Maybe we can come up with something more user friendly?
> 
> And check first with mls before patching.

Status? No change since nearly 2 month while Critical/P1
Comment 10 Michael Schröder 2010-06-16 18:00:44 UTC
Good point. Removed me from "Infoprovider" and downgraded to "normal".
Comment 11 Klaas Freitag 2010-06-28 07:42:22 UTC
Michael, it would certainly help if you could give your opinion on the questions in comment #6. If we have good support in the API, the problem can be solved quickly.
Comment 12 Michael Schröder 2010-06-28 08:51:18 UTC
Not diffing tars can be added very easily in the srcserver. I don't know if Marcus can live with that, though.
Comment 13 Marcus Meissner 2010-06-28 08:59:41 UTC
this biugreport is not about sources, it is about meta data.

diffing prettified xml isnt that hard.
Comment 14 Michael Schröder 2010-06-28 09:36:46 UTC
Oh, in that case it's not a regression, but just some feature to implement someday.

(Comment #6 was about sources)
Comment 15 Marcus Meissner 2010-06-28 09:42:14 UTC
Yes, and the day I wanted it implemented latest was September 2009.
Comment 16 Michael Schröder 2010-06-28 09:50:21 UTC
Maybe, but we can't fulfill every wish.
If you really want it you can help us implementing it, right?
Comment 19 Adrian Schröter 2010-06-30 09:07:22 UTC
I do not really understand what exactly is needed here.

We log all changes in a package, we log the submit request number also on each change.

Can you tell me which XML you speak about and which information you lack ?

Also a use case with (I know X and I want to find out Y) would be helpfull.
Comment 20 Marcus Meissner 2010-06-30 09:55:55 UTC
I am talking about the mails hermes sends out:

Date: Mon, 21 Jun 2010 19:32:17 +0000
From: hermes@opensuse.org
To: meissner@novell.com
Subject: [obs update] Package aide in security updated
X-Mailer: openSUSE Notification System


The package aide in security was updated.

--
Hermes messaging (http://hermes.opensuse.org)
openSUSE Build Service (https://build.opensuse.org/)



They need to contain what changed.

Same for the project change e-mails.
Comment 21 Klaas Freitag 2010-07-09 10:30:00 UTC
Note that OBS_PACKAGE_UPDATE only gets sent out if the package META data gets changed. That is probably not what you want.

You should subscribe to obs_srcsrv_commit which is the notification that is sent if the package was changed. It comes with a filelist of changes and a ready-to-copy osc command line which shows you the diff.

Full diff in the mail is critical atm, because backend diffs over all tarballs. That means the diffs can be huge. As soon as the diffing over tarballs can be avoided, we can add the diff to the mail.
Comment 22 Christopher Hofmann 2016-02-10 16:16:04 UTC
Hermes is obsolete for quite a while now. Hence I close those bugs now, finally.