!chair nirik jnsamyak patrikp

The Meeting Name is now releng

Not sure if it accepted the first command...

Meeting already in progress

Seems like yes. Good. Hello and welcome. 👋

0/

Let's wait for Kevin to join and we can discuss the migration as the first topic. Thank you for joining Ondrej Nosek .

Hello guys, I was expecting a video meeting, so I was little confused :)

hey hey it is a community meeting we usually do it in irc

Oh, irc. It's been a few years I used it regularly. Nice.

Not sure where Kevin is but I suppose we can start discussing and hopefully he joins so that he can chime in?

What do you think Samyak?

yes go ahead

in case of fedpkg, it's high priority anyways and needs to go in first - we need to address this out, i see Ondrej Nosek already reviewed the pr; we need to get the changes in and decide on the feasible day to flag things out and merge and roll out a patch/release;

Ondrej Nosek:

Ondrej Nosek: What's the process behind getting a patch in or since this is a big change will we need to do a release?

Ondrej Nosek: What's the process behind getting a patch in or since this is a big change will we need to do a release for fedpkg?

0

It can be either patch or full release. I am in the process of making a release this sprint.

Nice, so could you wait so patrikp could make those changes, and you do one release all together?

When packages are buit, they are sent to bodhi to be tested. But you all definitely know. I am setting 6 days usually

Same day I can put a status update for migration, in case things fails. tldr; pagure was suppose to be decomissioned this week, it is blocked due to scm migration only

So only the new API will be working, right? And users with old packages will get errors

When they try to get a branch or new package

yeah correct, as soon as it make it to stable. I think we could put a expection and ask quality folks to do a quick test and we could expidite this?

I was just about to ask that. That's my current understanding. We should drop all mentions of Pagure as it will stop working soon altogether and there will be a clear cutoff. After we migrate the repo, only the Forgejo one is supposed to work. So not both simultaneously.

correct, total move to forge, pagure will be gone, only dist-git based pagure which is seprate src.fpo remains

I had few minor comments on the PR. Did Patrik tested it with a new API?

Yeah, it's in one of the comments:

Testing

Installed locally with pip install -e . and tested against the Forgejo instance [1] (currently set to private):

fedpkg -C ./conf/etc/rpkg/fedpkg.conf set-forgejo-token

fedpkg -C ./conf/etc/rpkg/fedpkg.conf request-branch --repo testpkg f44

Successfully created a ticket [2] on the Forgejo issue tracker.

Hopefully, users would understand they should upgrade :)

I suppose you can't see the repository as it's private but we can add you to the org maybe?

What about releases? When I push updates into bodhi, rawhide release will start working immediately. With a new API

> Hopefully, users would understand they should upgrade :)

yeah hopefully

There is no waiting for a karma

In normal fedora branches, I can push to stable when karma is ready together. But not for rawhide

For normal fedora branches f43, f44, I can push to stable when karma is ready together. But not for rawhide

hmmm need to sort this out

apologies i had to go pick up my dinner order i’m back

Can't pushing the Rawhide update be delayed until flag day then? Also, getting karma for the other branches/releases shouldn't necessarily be that difficult.

When I push the update rawhide, I don't have a posssibility to change anything. Update is created immediately and approved

Or at least I am not aware of different approach

maybe we don’t build one for rawhide?

anyways assuming mostly our user base will be for stable releases

... untill other releases are ready?

yeah as soon as those are in we can just do a rawhide release too

I mentioned this in the PR. Hardcode a time/date of the switch into the code :)

just want to get these done before branching, because we will

be cutting a new rawhide release and things might end up in a weird state

I mentioned this in the PR: Hardcode a time/date of the switch into the code :)

ah cool haven’t got chance to look at your review but definitely

But it would reqire some extra effort from Patric ;)

But it would reqire some extra effort from Patrick ;)

But it would require some extra effort from Patrick ;)

Could you elaborate on some details of the proposed implementation?

Not sure I'm getting it.

In the code, there would be a "if" branch. After a deadline, a new API will be queried.

But until the deadline, old API is working. It requires both methods and the code would be duplicated a lot.

It might be solution in some situation, but it is quite demanding.

Not sure how this will come across, but if the old API stops working, the users will be "forced" to upgrade, right? Wouldn't it be enough to put in a warning of some sort to upgrade? Pagure will be going away completely very soon so that will be dead code soon anyway.

In the code, there would be a "if" branch. After a hardcoded deadline, a new API will be queried.

As soon as we migrate this repo Pagure is read-only.

But users need to upgrade to get the code that warns them

True...

I don't know the consequences and how fragile the API is. So you should say what way is good for you. We can:

1) release normal branches at the (relatively) same time. And rawhide branch later (<day).

2) hardcode the migration date

2. hardcode the migration date

1. release normal branches at the (relatively - minutes) same time. And rawhide branch later (\<day).

I don't know the consequences and how fragile the API is. So you should say what way is good for you. We can:

i think we should add these warning ⚠️

Users that don't upgrade will experience errors anyway

I don't know the consequences and how fragile the API is. So you should say what way is good for you. We can:

1. release normal branches at the (relatively - minutes) same time. And rawhide branch later (\<day).

2. hardcode the migration date for all released branches.

in my opinion, the first one seems right only thing I want is to actually add on a warning label for Migration and updation, and that the user were using. It needs to update fedpkg package in order to use all the functionality properly.

I am also leaning towards option 1 but it will be messy any way you slice it.

Should all this be part of a single fedpkg upgrade?

Best we can hope for is maybe sending an email to some mailing list (that definitely not all packagers will read) and hope that once it stops working for them they'll either upgrade or go digging.

Should all this be part of a single fedpkg upgrade, right?

Users who upgrade don't need warning. It should work for them seamlessly.

Yes.

Question is, what does a user for whom it just "randomly" stops working do.

And I don't know how to deliver warning for those who don't upgrade. Just mailing list :/

Yes. That's what I arrived at as well...

They'll be forced to upgrade eventually though, right? How much of an issue would that be?

What is the outlook how long the old API could live? 2 more weeks or less?

I would say less. As soon as the migrated repo is confirmed working Pagure will be switched to read only mode. This is the only thing blocking that from happening.

You can definitely write some info about migration at https://pagure.io/releng/fedora-scm-requests

well, there's a few other things blocking it, but yes, soonish...

Ah yes, we have a ticket open for archiving this, I'll definitely put it in the README with the new link.

I was curious whether they will give us enought time to deal with it

I was curious whether they will give us enough time to deal with it

what amount of time is needed? time to push an update with a message?

And deal with what exactly?

I am in the process of releasing a normal rpkg/fedpkg release. So I should finish until this Friday

Ah, and the migration changes would be part of the following release? Or you want to get it in this release?

Deal with the migration. But it seems, we have to finish it and then the door are closed :)

This change goes to the release if merged

hopefully, testers won't find additional issues there

hopefully, testers/community won't find additional issues there

hopefully, testers/community won't find additional issues there (and block the release)

so if we have a date/time to swich, what is that going to be?

release on friday seems like a busy weekend ;)

Let me clarify this. Patrick should polish the PR, then I will merge it and put it into the release. I will go through the process and I should provide a builds /update to bodhi until Friday. Specifically earlier than Friday, because I will take a PTO on this day

so switchover would be thursday then?

But earlier is better. I have another PTO Aug-5 to Aug 8

But I could ask somebody to push packages to stable

But I could ask somebody to push packages to stable If I am not present

I have questions related to the comments you left but we can talk about those in DMs (or the ticket itself) and get it in a mergeable state Tuesday/Wednesday. Would that work for your timeline?

I.e. get it merged by, say, Wednesday evening?

well, we need to announce this... today if we are switching later this week.

yes

and so we need to pick a time/date very soon

We can't swith it this week. Bodhi process takes few days

We can't switch it this week. Bodhi process takes few days

Time check, not sure if we're blocking the room for other meetings, but this is good discussion with Kevin here with us.

we can get testers/karma and push it quickly. it should not take days

We can't switch it this week. Bodhi process takes few days. Based on Karma, of course

then OK :)

also, if you push it to testing... people will try and use it and if it's not switched it will break _those_ people

true

so, it's all a mess I'm afraid. But I think the least messy would be to pick a time/date, switch toddlers/forge repo on, push the updates to testing and tell everyone to update to those versions after the time/date

and they go stable as quickly as we can after that

That would be this week or next then? If Ondrej wants to do the pushes this week, but we also want to give it karma and expedite the push to stable...

The repo and toddlers have to be in place by the time it lands in stable, right?

exactly that’s my thought

Will we synchronize in this chat? I mean in this app? Or should I communicate just with Patrick?

I would say let's use the releng room (the other link I sent in a DM).

we should not push any updates until we are ready to switch, IMHO

I'm the most junior of all so it'd be good to have other eyes on it as well...

yeah, we can go to releng room. :)

https://matrix.to/#/#releng:fedoraproject.org

#releng:fedoraproject.org

ok

patrikp: can you link Ondrej Nosek with migration ticket so they can just discuss and put those updates there?

Which updates?

^^

for the future fedpkg builds and updates

we can link that to ticket directly so everyone is in loop

Let's wrap it up here as we're over time and continue in the releng room.

Uh huh, great.

it was restarting for some reason...

Did it start the meeting in the first place_

Did it start the meeting in the first place?

yes.

something weird. I am looking

it's getting auth issues. I am not yet sure why