Announcing new anitya integration and de-orphaning process

[Pierre-Yves Chibon]

Good Morning Everyone,

Tomorrow we are planning on deploying a new version of pagure and
pagure-dist-git on production.

These changes come with two changes to the packager workflow:

* Anitya integration in dist-git

Something we lost when loosing pkgdb was the easy integration to anitya
(https://release-monitoring.org). With the coming changes we are getting them
back.

On the left hand-side column, there will be a drop-down button allowing to
change the settings for anitya for the project.
Existing status will be migrated from the fedora-scm-requests repo on pagure to
use this drop-down.
Using the fedora-scm-requests repo for the anitya integration will no longer be
supported.

* Change in the de-orphaning process

Currently if a package is orphaned, one has to open a ticket against the releng
project to adopt it. With these changes, anyone will be able to adopt orphaned
projects (not retired on master) directly from dist-git's UI.
If the project is retired or has been orphaned for too long, a ticket on the
releng project will still be required though.

Both of these changes can already be reviewed in staging at:
https://src.stg.fedoraproject.org

Looking forward for your feedback!
Pierre
_______________________________________________
devel-announce mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...

[Gwyn Ciesla]

<Fervent Applause>

-- 
Gwyn Ciesla
she/her/hers
------------------------------------------------ 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 26, 2019 6:13 AM, Pierre-Yves Chibon  wrote:
> Good Morning Everyone,
> Tomorrow we are planning on deploying a new version of pagure and
> pagure-dist-git on production.
> These changes come with two changes to the packager workflow:
> Anitya integration in dist-git
> Something we lost when loosing pkgdb was the easy integration to anitya
> (https://release-monitoring.org). With the coming changes we are getting them
> back.
> On the left hand-side column, there will be a drop-down button allowing to
> change the settings for anitya for the project.
> Existing status will be migrated from the fedora-scm-requests repo on pagure to
> use this drop-down.
> Using the fedora-scm-requests repo for the anitya integration will no longer be
> supported.
> Change in the de-orphaning process
> Currently if a package is orphaned, one has to open a ticket against the releng
> project to adopt it. With these changes, anyone will be able to adopt orphaned
> projects (not retired on master) directly from dist-git's UI.
> If the project is retired or has been orphaned for too long, a ticket on the
> releng project will still be required though.
> Both of these changes can already be reviewed in staging at:
> https://src.stg.fedoraproject.org
> Looking forward for your feedback!
> Pierre
>
> devel-announce mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 26, 2019 at 05:26:40PM +0000, Gwyn Ciesla via devel wrote:
> <Fervent Applause>

Seconded!

Zbyszek

[Jerry James]

On Tue, Nov 26, 2019 at 10:56 AM Zbigniew Jędrzejewski-Szmek
 wrote:
> On Tue, Nov 26, 2019 at 05:26:40PM +0000, Gwyn Ciesla via devel wrote:
> > <Fervent Applause>
>
> Seconded!

Thirded!  Or more like fifthed, actually.  This is great.

[Neal Gompa]

On Tue, Nov 26, 2019 at 12:22 PM Pierre-Yves Chibon  wrote:
> Good Morning Everyone,
>
> Tomorrow we are planning on deploying a new version of pagure and
> pagure-dist-git on production.
>
> These changes come with two changes to the packager workflow:
> Anitya integration in dist-git
>
> Something we lost when loosing pkgdb was the easy integration to anitya
> (https://release-monitoring.org). With the coming changes we are getting them
> back.
>
> On the left hand-side column, there will be a drop-down button allowing to
> change the settings for anitya for the project.
> Existing status will be migrated from the fedora-scm-requests repo on pagure to
> use this drop-down.
> Using the fedora-scm-requests repo for the anitya integration will no longer be
> supported.
> Change in the de-orphaning process
>
> Currently if a package is orphaned, one has to open a ticket against the releng
> project to adopt it. With these changes, anyone will be able to adopt orphaned
> projects (not retired on master) directly from dist-git's UI.
> If the project is retired or has been orphaned for too long, a ticket on the
> releng project will still be required though.
>
> Both of these changes can already be reviewed in staging at:
> https://src.stg.fedoraproject.org

Yaaaay! Thank you for that! This will make my life as a maintainer easier!

[Charalampos Stratakis]

----- Original Message -----
> From: "Pierre-Yves Chibon" 
> To: [e-mail]
> Sent: Tuesday, November 26, 2019 1:13:45 PM
> Subject: Announcing new anitya integration and de-orphaning process
>
> Good Morning Everyone,
>
> Tomorrow we are planning on deploying a new version of pagure and
> pagure-dist-git on production.
>
> These changes come with two changes to the packager workflow:
> Anitya integration in dist-git
>
> Something we lost when loosing pkgdb was the easy integration to anitya
> (https://release-monitoring.org). With the coming changes we are getting them
> back.
>
> On the left hand-side column, there will be a drop-down button allowing to
> change the settings for anitya for the project.
> Existing status will be migrated from the fedora-scm-requests repo on pagure
> to
> use this drop-down.
> Using the fedora-scm-requests repo for the anitya integration will no longer
> be
> supported.
> Change in the de-orphaning process
>
> Currently if a package is orphaned, one has to open a ticket against the
> releng
> project to adopt it. With these changes, anyone will be able to adopt
> orphaned
> projects (not retired on master) directly from dist-git's UI.
> If the project is retired or has been orphaned for too long, a ticket on the
> releng project will still be required though.
>
> Both of these changes can already be reviewed in staging at:
> https://src.stg.fedoraproject.org
>
> Looking forward for your feedback!
> Pierre
> _______________________________________________
> devel-announce mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

Thank you, that is awesome work!

[Mat Booth]

On Tue, 26 Nov 2019 at 17:21, Pierre-Yves Chibon 
wrote:
> Good Morning Everyone,
>
> Tomorrow we are planning on deploying a new version of pagure and
> pagure-dist-git on production.

Great stuff. I still don't understand why pkgdb was allowed to go away
before the replacements reached feature parity.

[Igor Gnatenko]

Because it is really hard to run two systems at the same time and keep them
synced?

On Thu, Nov 28, 2019, 14:43 Mat Booth  wrote:
> On Tue, 26 Nov 2019 at 17:21, Pierre-Yves Chibon 
> wrote:
> > Good Morning Everyone,
> >
> > Tomorrow we are planning on deploying a new version of pagure and
> > pagure-dist-git on production.
>
> Great stuff. I still don't understand why pkgdb was allowed to go away
> before the replacements reached feature parity.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Mat Booth]

On Fri, 29 Nov 2019 at 07:32, Igor Gnatenko <
[e-mail]> wrote:
> Because it is really hard to run two systems at the same time and keep

them synced?

Then let me rephrase. IMO the replacement system shouldn't have been
commissioned into production before it reached feature parity.

[Kevin Fenzi]

On Sat, Nov 30, 2019 at 02:25:08PM +0000, Mat Booth wrote:
> On Fri, 29 Nov 2019 at 07:32, Igor Gnatenko <
> [e-mail]> wrote:
> > Because it is really hard to run two systems at the same time and keep
>
> them synced?
>
> Then let me rephrase. IMO the replacement system shouldn't have been
> commissioned into production before it reached feature parity.

The problem was new features. The option was either to retire pkgdb and
move on, or implement new features in pkgdb at large development
time/cost. There were several things pkgdb couldn't handle, I can't
recall them all, but stream branches was a big one.

kevin

[Ben Rosser]

On Sat, Nov 30, 2019 at 3:00 PM Kevin Fenzi  wrote:
> On Sat, Nov 30, 2019 at 02:25:08PM +0000, Mat Booth wrote:
> > On Fri, 29 Nov 2019 at 07:32, Igor Gnatenko <
> > [e-mail]> wrote:
> > > Because it is really hard to run two systems at the same time and keep
> >
> > them synced?
> >
> > Then let me rephrase. IMO the replacement system shouldn't have been
> > commissioned into production before it reached feature parity.
>
> The problem was new features. The option was either to retire pkgdb and
> move on, or implement new features in pkgdb at large development
> time/cost. There were several things pkgdb couldn't handle, I can't
> recall them all, but stream branches was a big one.

Well, there *was* a third option: wait until pagure reached feature
parity with pkgdb before implementing new features like stream
expansion.

But in any case, I'm really glad that we do now finally have anitya
integration and easy de-orphaning back in pkgdb. Thanks to everyone
who made this happen!

Ben Rosser

[Jun Aruga]

> Existing status will be migrated from the fedora-scm-requests repo on pagure to

use this drop-down.
> Using the fedora-scm-requests repo for the anitya integration will no longer be

supported.

Thank you for the anitya integration feature.

I have 2 questions. After the migration will be finished,

1.  When just changing the "Monitoring status" drop-down button to
"Monitoring" is good enough to receive the email "[Bug NNNNNNN]
<package-name>-<version> is available"?

Following steps are replaced with it, right?
> https://fedoraproject.org/wiki/Upstream_release_monitoring
>
> Get bug reports for a project's releases in Fedora's Bugzilla with three steps:
> Add the project to anitya.
> Map the project to a Fedora package in anitya.
> File a pull-request on the releng/fedora-scm-requests repo to tweak the monitoring setting for your packages.

2. Is it possible to put a link of a package's Antiya project page
around "Monitoring status" of the rpm/foo page?
It looks useful to know and edit the setting easily.

For example. rpms/ruby https://src.fedoraproject.org/rpms/ruby
  => https://release-monitoring.org/project/4223/

--
Jun | He - His - Him

[Pierre-Yves Chibon]

On Mon, Dec 09, 2019 at 05:15:36PM +0100, Jun Aruga wrote:
> > Existing status will be migrated from the fedora-scm-requests repo on pagure to
>
> use this drop-down.
> > Using the fedora-scm-requests repo for the anitya integration will no longer be
>
> supported.
>
> Thank you for the anitya integration feature.
>
> I have 2 questions. After the migration will be finished,
> When just changing the "Monitoring status" drop-down button to
>
> "Monitoring" is good enough to receive the email "[Bug NNNNNNN]
> <package-name>-<version> is available"?

`Monitoring` means: you get a bugzilla ticket
`Monitoring and scrach builds` means: you get the bugzilla ticket and an
    attempt to do a scratch build for the new version
`No-Monitoring` means: nothing happens when a new version is detected
> Following steps are replaced with it, right?
> > https://fedoraproject.org/wiki/Upstream_release_monitoring
> >
> > Get bug reports for a project's releases in Fedora's Bugzilla with three steps:
> > Add the project to anitya.
> > Map the project to a Fedora package in anitya.
> > File a pull-request on the releng/fedora-scm-requests repo to tweak the monitoring setting for your packages.

Correct, that wiki page should be updated, these steps are no longer needed.
> Is it possible to put a link of a package's Antiya project page
>
> around "Monitoring status" of the rpm/foo page?
> It looks useful to know and edit the setting easily.
>
> For example. rpms/ruby https://src.fedoraproject.org/rpms/ruby
>   => https://release-monitoring.org/project/4223/

Technically doable, however, release-monitoring is distro agnostic, so I do not
know if upstream will want to put too much Fedora specific content in it.

Adding a link from dist-git to release-monitoring should be easier, I even seem
to remember that pkgdb2 used to do that, I'll have to see how it was doing it.

Pierre

[Jun Aruga]

> > Is it possible to put a link of a package's Antiya project page
> >
> > around "Monitoring status" of the rpm/foo page?
> > It looks useful to know and edit the setting easily.
> >
> > For example. rpms/ruby https://src.fedoraproject.org/rpms/ruby
> >   => https://release-monitoring.org/project/4223/
>
> Technically doable, however, release-monitoring is distro agnostic, so I do not
> know if upstream will want to put too much Fedora specific content in it.

You meant the "upstream" was release-monitoring (Antiya)?
I thought we did not need to modify release-monitoring.
I thought we need to modify Pagure: https://src.fedoraproject.org for that.
If the Pagure upstream is the distro agnostic, how about adding a
configuration item
"Mappings Distribution" (Fedora/Alpine and etc) that is considered to
access to release-monitoring from Pagure?
> Adding a link from dist-git to release-monitoring should be easier, I even seem
> to remember that pkgdb2 used to do that, I'll have to see how it was doing it.

Good news.
If it is hard to implement it, just putting the following URL to
search by a package name in release-monitoring is still helpful for
me.
https://release-monitoring.org/projects/search/?pattern=<package_nane>
For example: https://release-monitoring.org/projects/search/?pattern=ruby

[Pierre-Yves Chibon]

On Tue, Dec 10, 2019 at 02:51:57PM +0100, Jun Aruga wrote:
> > > Is it possible to put a link of a package's Antiya project page
> > >
> > > around "Monitoring status" of the rpm/foo page?
> > > It looks useful to know and edit the setting easily.
> > >
> > > For example. rpms/ruby https://src.fedoraproject.org/rpms/ruby
> > >   => https://release-monitoring.org/project/4223/
> >
> > Technically doable, however, release-monitoring is distro agnostic, so I do not
> > know if upstream will want to put too much Fedora specific content in it.
>
> You meant the "upstream" was release-monitoring (Antiya)?
> I thought we did not need to modify release-monitoring.
> I thought we need to modify Pagure: https://src.fedoraproject.org for that.
> If the Pagure upstream is the distro agnostic, how about adding a
> configuration item
> "Mappings Distribution" (Fedora/Alpine and etc) that is considered to
> access to release-monitoring from Pagure?
> > Adding a link from dist-git to release-monitoring should be easier, I even seem
> > to remember that pkgdb2 used to do that, I'll have to see how it was doing it.
>
> Good news.
> If it is hard to implement it, just putting the following URL to
> search by a package name in release-monitoring is still helpful for
> me.
> https://release-monitoring.org/projects/search/?pattern=<package_nane>
> For example: https://release-monitoring.org/projects/search/?pattern=ruby

Ok, I think I had miss-understand you but it looks like we're one the same line
again.

Thanks for your inputs!

Pierre

[Rahul Sundaram]

Hi

On Mon, Dec 9, 2019 at 11:43 AM Pierre-Yves Chibon 
wrote:
> `Monitoring` means: you get a bugzilla ticket
> `Monitoring and scrach builds` means: you get the bugzilla ticket and an
>     attempt to do a scratch build for the new version

I was wondering how hard it would be to open a pull request if a scratch
build was successful.  For minor version bumps, this can be helpful for
maintainers

Rahul

[Pierre-Yves Chibon]

On Fri, Dec 13, 2019 at 06:41:35AM -0500, Rahul Sundaram wrote:
> Hi
>    On Mon, Dec 9, 2019 at 11:43 AM Pierre-Yves Chibon
>    <[1][e-mail]> wrote:
>  `Monitoring` means: you get a bugzilla ticket
>  `Monitoring and scrach builds` means: you get the bugzilla ticket and an
>      attempt to do a scratch build for the new version
>
> I was wondering how hard it would be to open a pull request if a scratch
>    build was successful.  For minor version bumps, this can be helpful for
>    maintainers

It's on the roadmap but there is no ETA for this yet.
I believe the idea is even to replace entirely the bugzilla ticket by a PR.

Pierre

[Miro Hrončok]

On 26. 11. 19 13:13, Pierre-Yves Chibon wrote:
> Anitya integration in dist-git
>
> Something we lost when loosing pkgdb was the easy integration to anitya
> (https://release-monitoring.org). With the coming changes we are getting them
> back.
>
> On the left hand-side column, there will be a drop-down button allowing to
> change the settings for anitya for the project.
> Existing status will be migrated from the fedora-scm-requests repo on pagure to
> use this drop-down.
> Using the fedora-scm-requests repo for the anitya integration will no longer be
> supported.

I have updated https://fedoraproject.org/wiki/Upstream_release_monitoring to 
reflect this, it still had the old workflow documented.

I'd appreciate if somebody can go trough the page and verify it makes sense now.