Hi everyone,
The next pkgdb2 release (1.24) will be a pretty big releases, to give you an idea this is its current changelog:
- Allow package admins to retire a package - Anitya integration on the package's detail page - Fix orphaning package having a group as PoC - Add the possibility to request action from the pkgdb admins and releng. These actions include: - Request a new package to be added to pkgdb (after completed its review on bugzilla) - Request a new branch for an existing package - When requesting a new branch, current package admins have 1 week to agree or disagree with the request - If they disagree the request is blocked (they have to specify a reason) - After a week, or earlier if they agree, the request is passed onto the pkgdb admins and releng for processing.
These new actions can be processed via pkgdb-admin which is shipped as part of packagedb-cli (ie next to pkgdb-cli).
Since these changes might be pretty big and impact multiple person, I would like to hear when people think it would be best to make the release.
Note: I will not do it today, but basically I could from tomorrow :)
Note2: As it will likely take a little time for people to get adjusted to the new workflow (that needs to be documented & so on), there will likely be a time for pkgdb admins and releng when they will have to check both bugzilla and pkgdb.
Note3: As I would not be surprised that we run into some bugs and since freeze is not that far either, the earlier the better :)
Thanks,
Pierre
PS: Also sent to the rel-eng list but please let's keep this on the infra list
On Wed, 18 Mar 2015 15:25:48 +0100 Pierre-Yves Chibon pingou@pingoured.fr wrote:
Hi everyone,
The next pkgdb2 release (1.24) will be a pretty big releases, to give you an idea this is its current changelog:
...snip good stuff...
Since these changes might be pretty big and impact multiple person, I would like to hear when people think it would be best to make the release.
Note: I will not do it today, but basically I could from tomorrow :)
I'd say do it tomorrow. ;)
Well, is it already in stg and working there? I'd say push to staging and make sure there's nothing obviously broken, then go to prod.
Note2: As it will likely take a little time for people to get adjusted to the new workflow (that needs to be documented & so on), there will likely be a time for pkgdb admins and releng when they will have to check both bugzilla and pkgdb.
Right. However, we should be able to roll this out and keep using the old process for new packages and branches right? ie, maintainers don't even need to know this is there unless we ask them to try it?
So, we should be able to put it in place and have a small group of folks test things and fix issues, and only then announce to maintainers to switch to the new process.
Note3: As I would not be surprised that we run into some bugs and since freeze is not that far either, the earlier the better :)
I agree.
kevin
On Wed, Mar 18, 2015 at 09:44:56AM -0600, Kevin Fenzi wrote:
On Wed, 18 Mar 2015 15:25:48 +0100 Pierre-Yves Chibon pingou@pingoured.fr wrote:
Hi everyone,
The next pkgdb2 release (1.24) will be a pretty big releases, to give you an idea this is its current changelog:
...snip good stuff...
Since these changes might be pretty big and impact multiple person, I would like to hear when people think it would be best to make the release.
Note: I will not do it today, but basically I could from tomorrow :)
I'd say do it tomorrow. ;)
Well, is it already in stg and working there?
The main changes are running in stg yes (the new package/branch requests), the other changes are either running already in prod (backported to 1.23) or are small enough that I do not expect any problem.
I'd say push to staging and make sure there's nothing obviously broken, then go to prod.
Sure, I can cut a 1.24 tomorrow and push it to prod.
Note2: As it will likely take a little time for people to get adjusted to the new workflow (that needs to be documented & so on), there will likely be a time for pkgdb admins and releng when they will have to check both bugzilla and pkgdb.
Right. However, we should be able to roll this out and keep using the old process for new packages and branches right? ie, maintainers don't even need to know this is there unless we ask them to try it?
Yes, since we do not touch bugzilla nor the way packages are created in pkgdb, the old process will work just fine.
So, we should be able to put it in place and have a small group of folks test things and fix issues, and only then announce to maintainers to switch to the new process.
Sounds good :) Only people might notice the big blue button on the front page: https://admin.stg.fedoraproject.org/pkgdb/
That's one way to make them aware I guess ;-)
Pierre
On Wed, Mar 18, 2015 at 05:00:31PM +0100, Pierre-Yves Chibon wrote:
On Wed, Mar 18, 2015 at 09:44:56AM -0600, Kevin Fenzi wrote:
On Wed, 18 Mar 2015 15:25:48 +0100 Pierre-Yves Chibon pingou@pingoured.fr wrote:
Hi everyone,
The next pkgdb2 release (1.24) will be a pretty big releases, to give you an idea this is its current changelog:
...snip good stuff...
Since these changes might be pretty big and impact multiple person, I would like to hear when people think it would be best to make the release.
Note: I will not do it today, but basically I could from tomorrow :)
I'd say do it tomorrow. ;)
Well, is it already in stg and working there?
The main changes are running in stg yes (the new package/branch requests), the other changes are either running already in prod (backported to 1.23) or are small enough that I do not expect any problem.
I'd say push to staging and make sure there's nothing obviously broken, then go to prod.
Sure, I can cut a 1.24 tomorrow and push it to prod.
Note2: As it will likely take a little time for people to get adjusted to the new workflow (that needs to be documented & so on), there will likely be a time for pkgdb admins and releng when they will have to check both bugzilla and pkgdb.
Right. However, we should be able to roll this out and keep using the old process for new packages and branches right? ie, maintainers don't even need to know this is there unless we ask them to try it?
Yes, since we do not touch bugzilla nor the way packages are created in pkgdb, the old process will work just fine.
So, we should be able to put it in place and have a small group of folks test things and fix issues, and only then announce to maintainers to switch to the new process.
Sounds good :) Only people might notice the big blue button on the front page: https://admin.stg.fedoraproject.org/pkgdb/
That's one way to make them aware I guess ;-)
I'd suggest two announcements: One by Pierre through his blog, and one to the devel@ list so interested people can participate in testing and maintainers are aware of how the new functions impact (or don't impact) their work for now.
On Wed, Mar 18, 2015 at 05:00:31PM +0100, Pierre-Yves Chibon wrote:
On Wed, Mar 18, 2015 at 09:44:56AM -0600, Kevin Fenzi wrote:
On Wed, 18 Mar 2015 15:25:48 +0100 Pierre-Yves Chibon pingou@pingoured.fr wrote:
Note2: As it will likely take a little time for people to get adjusted to the new workflow (that needs to be documented & so on), there will likely be a time for pkgdb admins and releng when they will have to check both bugzilla and pkgdb.
Right. However, we should be able to roll this out and keep using the old process for new packages and branches right? ie, maintainers don't even need to know this is there unless we ask them to try it?
Yes, since we do not touch bugzilla nor the way packages are created in pkgdb, the old process will work just fine.
This was my only concern. Sounds good to me to deploy as soon as is convenient. We have just short of two weeks before freeze-time to fix bugs that pop up, which seems like plenty.
infrastructure@lists.fedoraproject.org
-
Kevin Fenzi -
Paul W. Frields -
Pierre-Yves Chibon -
Ralph Bean