Re: Don't add default contents in `fedpkg request-branch` tickets Was: Re: can we merge package.cfg into master

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, October 4, 2019 10:57:05 AM CEST Fabio Valentini wrote:
> 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.

For the packages I maintain, I'm not sure the playground is worth another
branch.  So I'd personally let this work on someone else probably.  Or
does the fact that I maintain epel8 imply I have to take care of
epel8-playground as well?

Pavel

> > 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
> 



_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux