On Friday, October 4, 2019 10:46:17 AM CEST Nicolas Chauvet wrote:
Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup
<praiskup(a)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 <sergio(a)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