Bug 32947 - Add support to mgaadv to handle backports
Summary: Add support to mgaadv to handle backports
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 9
Hardware: All Linux
Priority: Normal enhancement
Target Milestone: ---
Assignee: All Packagers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-07 23:05 CET by Dave Hodgins
Modified: 2024-03-08 21:40 CET (History)
6 users (show)

See Also:
Source RPM: mga-advisories-0.27-1.mga9
CVE:
Status comment:


Attachments

Description Dave Hodgins 2024-03-07 23:05:22 CET
Now that the backports-announce mailing list has been created, advisories
for backports should now be handled using svn and mgaadv, similar to the
way updates are currently handled, but with the advisories published to
the new mailing list.

As the mga-advisories package has not assigned maintainer, assigning to all
packagers.

This is needed for Mageia 9 and later releases.
Comment 1 Dan Fandrich 2024-03-08 02:25:02 CET
This increases the workload for issuing a new backport, but if QA is fine with that it's a clean solution. The alternative is to still issue an automated message to backports-announce when a backports move happens, but with much less information (namely, all the manual stuff added to the advisory).

CC: (none) => dan

Comment 2 Dave Hodgins 2024-03-08 03:45:02 CET
As there are no "backports updates" repos, it won't only be used for new
backports. It will be used for updates to backports as well, so the user's
selecting whether or not to install a backport update will need the same
information so they can decide if they want to install the updated backport.

In my opinion, using the same format and methods for the advisories makes
sense, even though less testing is done.

I'm no longer the leader of the qa team, so it's not up to me.

Adding tj to the cc list, who should decide.

CC: (none) => andrewsfarm

Comment 3 Thomas Andrews 2024-03-08 14:23:52 CET
I agree. 

There has been much frustration in QA about our policy of putting new packages in backports in a stable release. Members feel, and rightly so, that such backports get lost, and few Mageia user know that they even exist. The new mailing list, with an occasional blog post when there is something of import, should help with those concerns.

But it is also correct that with that new publicity more thorough information should be easily available so those who consider the backports can make informed decisions. So we need some kind of advisory.

There would be little more work for those in QA writing advisories, as we have few backports. (At least, at present.)

I also think that every post to ML and/or blog should contain the warning that backports do not receive the same level of testing as updates, etc. It may seem redundant to do it every time, but if it's there every time we can point out that users were warned, if the worst happens.
Comment 4 Marja Van Waes 2024-03-08 16:41:13 CET
@ Yves

Would it be possible for you to update mga-advisor, so that it can handle backports, too?

CC: (none) => marja11, yvesbrungard

Morgan Leijström 2024-03-08 16:47:31 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32929
CC: (none) => fri

Comment 5 papoteur 2024-03-08 17:10:58 CET
(In reply to Marja Van Waes from comment #4)
> @ Yves
> 
> Would it be possible for you to update mga-advisor, so that it can handle
> backports, too?
Hi Marja,
No objection, except I don't see anything specific to adapt for backports in mga-advisor.
Or perhaps another category for bugfix/security?
Comment 6 Marja Van Waes 2024-03-08 17:51:37 CET
(In reply to papoteur from comment #5)
> (In reply to Marja Van Waes from comment #4)
> > @ Yves
> > 
> > Would it be possible for you to update mga-advisor, so that it can handle
> > backports, too?
> Hi Marja,
> No objection, except I don't see anything specific to adapt for backports in
> mga-advisor.
> Or perhaps another category for bugfix/security?

Well, if it would be possible to get it to retrieve the right srpm, that would be really nice

Now, for bug 32854, it gets (in the editor, before writing the advisory) an old version:

  9 core php-8.2.16-1.mga9

instead of 

  9 core backports php-8.3.3-4.mga9

The latter can't even be done manually.

However, I don't know whether "9 core backports <srpm>" is useful, it would result in something like:

  src:
    9:
      core:
           backports:
           - php-8.3.3-4.mga9

@ danf

It might be better, as Yves suggested, to add a "backports" type (like we have bugfix and security types). In that case we'd have

type: backports 

and the "src:" part would be, for this example:


src:
  9:
    core:
    - php-8.3.3-4.mga9


.
Comment 7 katnatek 2024-03-08 18:37:44 CET
I'm against this idea, and in general of the idea de follow the format of regular updates to announce backports.

I think a mail could be sent when the packages are ready to test and other when are moved from backport testimg to backport

I'll support the final decision and if is following this way, I also like the papoteur tool can make it easy
Comment 8 Len Lawrence 2024-03-08 21:40:54 CET
Sorry if I am late for the party.  I did not know there was a problem because in the past backports did just appear in the testing lists.  There is nothing specific in qarepo about backports and just checking, no, backports and backports-testing are not enabled in my repository list.  So I do not have any strong opinions about this.  For advisories another category sounds necessary.

CC: (none) => tarazed25


Note You need to log in before you can comment on or make changes to this bug.