So, PkgDB now comes with a big fat warning saying: "Attention! PkgDB will be replaced during the week of July 10th, 2017. Please read the following for migration instructions: https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb";
If I go there I find no "migration instructions" whatsoever, the pararagraph on "How Is PkgDB's Functionality Being Replaced" is ridiculously short and points to a "Pagure over Dist-Git (placeholder link)" which obviously points to nowhere. All these "to be written" in the timeline for June (!) don't make me overly confident in that agenda. Saying "Do something or else" without telling us "what" nor "what else" is a really good way to put off contributors, but no good way to get everyone in the boat for the move. Really, I'm all in for weeding out the git branch madness that we have now in dist-git (too many cherry-picks, insane merge directions) and I do hope that entanglich branches from releases will help that purpose. But please, take a step back and think about how and what you communicate to packagers, that is "infra-users". Michael Adam Samalik venit, vidit, dixit 04.06.2017 12:43: > This enables us to have branches that make more sense for individual > packages - so we can save work by having just one branch for one version > acrsoss releases, or to offer more versions or "streams". A slide [1] > from my recent talk demonstrates the possibilities - and also shows why > branches are not always just versions. It talks about modules, but it's > the same for packages, too. > > I like your work, guys! If you want to use any of the graphic from my > slides in a documentation or anywhere else, please feel free to do so. I > can even tweak it if you like. > > [1] https://asamalik.fedorapeople.org/modularity-dorscluc-2017/#/1/2 > > On Fri, May 26, 2017 at 9:42 PM, Ralph Bean <rb...@redhat.com > <mailto:rb...@redhat.com>> wrote: > > Hello, > > As part of the Factory 2.0 and Modularity efforts[1], we’ve been > developing a plan to migrate to an “arbitrary” branching model from > our current model of one branch per release (as had been discussed at > Flock and DevConf[2]). > > The main motivation behind this is to enable functionality required by > Modularity[3] and to ultimately reduce some package maintenance > burden. For some packages, it makes sense to have only a single branch > that feeds into multiple releases. For other packages, it makes sense > to have multiple branches which correlate with multiple upstream minor > releases. Today, our source branches are tied to the distro release, > via PkgDB. We want to decouple that and use modules to put it all > back together again. > > To make this happen requires significant infrastructure changes. Our > proposed plan[4] is to decommission PkgDB entirely and to replace it > with a combination of PDC[5] and pagure over dist-git. (Tangentially, > getting pagure over dist-git to play nicely with PkgDB was a > challenge. This route gets us to a pull-request interface for spec > files quicker.) > > We have brought this Change to FESCo[6][7][8] who expressed general > agreement on the project but also concern that the community may be > caught by off guard by the removal of PkgDB. As part of this change, > we have proposed a timeline[9] that outlines the steps we plan to take > to actually proceed with the migration. Please review that if you have > time and provide feedback. We are most concerned with missing > scripts/tools that may rely on PkgDB’s API. If you can think of any > that we may have overlooked, please let us know and we will add it to > the timeline! > > We are meeting again with FESCo next Friday, June 2nd, where a > decision will be made on the Change. Any feedback before that would be > greatly appreciated. > > Ralph and Matt, > From the so-called Factory 2.0 team > > [1] https://fedoraproject.org/wiki/Infrastructure/Factory2 > <https://fedoraproject.org/wiki/Infrastructure/Factory2> > [2] https://youtu.be/5gqccjyjwFk?t=26m27s > <https://youtu.be/5gqccjyjwFk?t=26m27s> > [3] https://docs.pagure.org/modularity/ > <https://docs.pagure.org/modularity/> > [4] > > https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching > > <https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching> > [5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter > <https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter> > [6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching > <https://fedoraproject.org/wiki/Changes/ArbitraryBranching> > [7] > https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html > > <https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html> > [8] > https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html > > <https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html> > [9] > https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline > <https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline> > > _______________________________________________ > devel-announce mailing list -- > devel-annou...@lists.fedoraproject.org > <mailto:devel-annou...@lists.fedoraproject.org> > To unsubscribe send an email to > devel-announce-le...@lists.fedoraproject.org > <mailto:devel-announce-le...@lists.fedoraproject.org> > > > > > -- > > Adam Šamalík > --------------------------- > Software Engineer > Red Hat > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
