On Fri, Oct 4, 2019 at 10:47 AM Nicolas Chauvet <kwizart@xxxxxxxxx> wrote: > > Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup <praiskup@xxxxxxxxxx> a écrit : > > > > On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote: > > > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote: > > > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto <sergio@xxxxxxxxxx> > > > > wrote: > > > > > Hi, > > > > > epel 8 brings a new file called package.cfg, I strongly prefer to > > > > > keep > > > > > branches mergeable with fast forward , may we merge this into > > > > > master ? > > > > > like I did in pngquant [1] > > > > > > > > > > > > > It disables the normal build behavior for all non-master branches, so > > > > you don't want to do that. > > > > > > Well , I want keep my branches mergeable ! > > > > Same problem. I came across several epel8 branch requests ... and there > > always is some default 'package.cfg' file I don't really mind as I > > observed (the builds against epel8 just succeed without that). More, > > sometimes the README.md is added. I'm not sure about this, but I think without the package.cfg file, builds won't be submitted to both epel8 and epel8-playground, but only to epel8? This might not be what you want. Fabio > I've tried to report the issue here: (although it's for another use-case). > https://pagure.io/fedpkg/issue/354 > > Allowing to have the same package.cfg to describe the appropriate > behaviour for all branches would be nice. > But there is probably a need to improve the package.cfg format and > associated behavior. > > > Could we stop doing that? Unless it is really reasonable, I don't plan to > > make differences in maintained branches, and to achieve that with the > > current approach -- I have to go the ugly way (merge epel8 to master and > > vice versa, so histories in all branches are ugly forever). > I don't get why people use that, it doesn't solve the problem but make it worse. > Best is to merge newer branches into olders and avoid any merge commit > in master. (some projects forbid that). > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
