MRE cards for pinot

[Bryce Harrington]

The MRE task cards are now added to Launchpad, and I've confirmed
they're visible in Pinot.  You'll need to assign yourself and make
adjustments so they match your plans.

    http://pinot.endarchy.org/merges-schedule

---

The "magic" that makes these bugs show up as MRE cards in Pinot is to
have 'canonical-server' subscribed, and be tagged needs-mre-backport.
Having a milestone targeted is important but not strictly required.
If you need to add more MRE cards, or if you have an existing MRE bug
report you'd like to use instead of the generated one, that's all that
should be needed.

I've generated these with a default description that loosely follows the
SRU template for convenience, but of course feel free to erase and redo
all that.  Same with the title - I know each of us has some conventions
in how we do our MREs, don't feel you have to change your conventions
just change the bug title as you wish.

I've set default milestones for all the MREs per the config file as
discussed up thread, but again please adjust as desired according to
what you plan.

Currently I don't have a way of easily customizing which releases a
given MRE will target, so I've targeted them all to focal, jammy and
lunar by default.  Please delete or mark as Won't Fix the bug tasks for
any series your MRE is not going to target.  For example, open-vm-tools
only backports to the latest LTS, so I've deleted the Focal bug task.
(In the future maybe I can make this more configurable per-package but
for now it targets MRES to `ubuntu-distro-info --supported` minus the
active devel release.)

You'll note that in addition to the bug tasks for each of the target
Ubuntu series, they also have the top level general bug task that
targets mantic.  I haven't tested if it's safe to close that one, even
though there's obviously no backporting work to do for mantic; it might
remove the card from the Pinot board, but I'm not sure.  Feel free to
experiment and/or give feedback; if there are problems I'll investigate
once I'm back.


If the above makes you wonder, gee how's all that been implemented?
Well you're in luck because my MP with all the changes is up for review!
Review feedback would be very much appreciated:

    https://code.launchpad.net/~bryce/pdbq/+git/pdbq/+merge/447244


Bryce


P.S. I'll be on PTO next week, and hopefully there will be no issues while
I'm away but if so accept my apologies and I'll investigate once I'm back.


On Wed, Jul 19, 2023 at 04:46:43PM -0700, Bryce Harrington wrote:
> Following up on the question from this morning regarding the missing
> cards for the MRE tasks for various packages, here's the config for what
> we have presently:
> 
> 
>                                                                             
>     software = [
> 	{
>             'software-name': 'dpdk',
>             'software-type': 'deb',
>             'information-type': 'public',
>             'packages': ['dpdk'],
>             'update-schedule': ['Mar', 'Jun', 'Sep', 'Dec'],
>         },
>         {
>             'software-name': 'postgresql',
>             'software-type': 'deb',
>             'information-type': 'public',
>             'packages': ['postgresql-10', 'postgresql-12', 'postgresql-13'],
>             'update-schedule': ['Feb', 'May', 'Aug', 'Nov'],
>         },
>         {
>             'software-name': 'open-vm-tools',
>             'software-type': 'deb',
>             'information-type': 'public',
>             'packages': ['open-vm-tools'],
>             'update-schedule': ['Apr', 'Oct'],
>         },
>         {
>             'software-name': 'container-stack',
>             'software-type': 'deb',
>             'information-type': 'public',
>             'packages': ['docker.io', 'containerd', 'runc'],
>             'update-schedule': ['Feb', 'May', 'Aug', 'Nov'],
>         },
>     ]
> 
> IIRC eleven MREs were mentioned at the meeting today but unfortunately I
> didn't capture notes on what those were.  So please review the above
> list and let me know of additions or changes needed.
> 
> Notice that each "software" object can consist of one or more source
> packages, so we can track sets like the container stack as well as
> things like postgres that have different source packages per major
> release.  Even accounting for these, my list has only 8 at most so I
> know I'm missing some of our mentioned items.
> 
> I'll run the script to generate the tracking bugs for these after
> tomorrow's meetings.
> 
> Bryce