On Friday, October 4, 2019 10:46:17 AM CEST Nicolas Chauvet wrote: > Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup <prais...@redhat.com> 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 <ser...@serjux.com> > > > > 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'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.
TBH, TL;DR, I need to study why package.cfg is actually useful. But since everything worked even without the file, I won't complain. I just remove it and ... business as usual for now. It would be just much nicer if I didn't have to have ugly histories. The predefined README.md/package.cfg seemed to be trivial enough so anyone interested could even add that file manually (or request explicitly in ticket). > > 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). I personally don't understand why to diverge branches that _are expected_ to have the same contents (some packages don't allow this). Any random reviewer needs to ask what are the differences between the branches (is epel-7 behind master? is behind f31, etc.), and it is wasting of efforts. Same hash makes it absolutely obvious. And if master is above -- you see the older fast-forward'able branches in git-log. Pavel _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
