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> 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 > [2] https://youtu.be/5gqccjyjwFk?t=26m27s > [3] https://docs.pagure.org/modularity/ > [4] https://fedoraproject.org/wiki/Infrastructure/Factory2/ > Focus/ArbitraryBranching > [5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter > [6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching > [7] 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 > [9] https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline > > _______________________________________________ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-leave@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
