Re: Ideas and proposal for removing changelog and release fields from spec file

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

 



On Tue, Feb 25, 2020 at 3:12 PM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
>
> On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> > On Tue, Feb 25, 2020 at 2:47 PM Remi Collet <Fedora@xxxxxxxxxxxxxxxxx> wrote:
> > >
> > > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> > >
> > > >   - You can easily opt-in by using the macros
> > >
> > > Please keep opt-in as a mandatory need for such a change.
> > >
> > >
> > > To be clear, I will be (perhaps the only) one to not use it.
> > >
> > >
> > > For now spec file are self-contained, which is nice.
> > >
> > > I don't like the idea of generated / external stuff related
> > > to "storage" or "build system"
> > >
> > >
> > > Sorry, to be again the old bad guy which don't like changes.
> > >
> > > Remi
> >
> > FWIW, I agree. Maybe I'm getting old as well >:-D
> >
> > I don't think it's a good idea to use any information from outside the
> > dist-git repository as a source of truth for anything.
> > The big benefit of only using the git repository as source of
> > information is that it is immutable, reproducible, and cannot be
> > changed after commits have been pushed.
> > The git repository data is also available for working on packages
> > *offline*, in contrast to having to ask koji for the number of builds
> > since X ...
>
> The way I see it is this:
> With the number of commits+number of build idea, you get the same results
> locally and in bodhi.
> Locally fedpkg build or rpmbuild -ba will override the existing RPM
> In koji, it will simply append a .1 to the release to avoid overriding the
> existing RPM.
> But the content and release, except for two characters, will be the same.

(snip)

> That being said, there seems to be a consensus forming about wanting to rely
> only on number of commits (though, we still have the upgrade path issue to sort
> out).

Hi Pierre,

After reporting a few upgrade path bugs for (I think) fedora 28 and
29, I was told that "we don't care about upgrade path anymore", since
"dnf system-upgrade" operates in "distro-sync" mode by default, since
a few releases ago.

So I don't see upgrade path as a (big) concern here. There may be
package downgrades at system-upgrade time, but that's already the case
today - most of the time because either people forget to build for
fedora-branched after the branch point, or because they forget to
submit bodhi updates after update-testing activation point. Whereas
those two are "real" downgrades, any downgrades caused by the new
commit counting would only be "downgrade by number but upgrade in
content".

Fabio

Side note: I've been meaning to propose dropping Epoch because of this
"we don't care about upgrade path anymore", but I've not gotten around
to do that yet 😈️

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