On Wed, Jun 28, 2017 at 08:20:29AM -0600, Kevin Fenzi wrote:
On 06/28/2017 02:57 AM, Pierre-Yves Chibon wrote:
> I did not realize this before, but this will impact the decommissioning of
> The idea was to deploy pagure on dist-git on July 5th and deprecate pkgdb on
> July 10th.
> So could/should we postpone this to say, deploy pagure on dist-git on the 10th?
> and deprecate pkgdb on the 17th?
> (The pagure part worries me less since it's a new service which should have
> minimal impact on the existing one).
> The issue is then, what do we do is release slips?
> PS: on a personal note, I'm not sure how much I'll be around on the 5th
> afternoon, 6th and 7th, so postponing to the 10th is actually appealing to me.
Well, the folks with the short timeline/constraints are the factory 2.0
folks, so lets see what they say here. ;)
I'm fine with doing it later, but this may impact more milestones they
have. I agree the pagure part might be less impactfull since it should
hopefully not affect f26 efforts. The pkgdb drop could affect f26 (say a
blocker couldn't be built or the like), so it might be better to do that
when f26 is already go.
Some of our early project deadlines are deadlines because they block
further work on other infrastructure tools. Those make me anxious,
because if one slips, then *everything* slips.
Luckily, the ArbitraryBranching Change is not one of those. We set an
early deadline for ourselves so that we could provide maximum time
during the F27 development cycle for packagers and "modulers" (module
maintainers?) to use and acclimate to new branch-related tooling.
Taking that into account, slipping the pkgdb change by a week is not a
big deal from my PoV.
Thanks for the heads up!