Re: [Fedora-packaging] 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]

 



Le 2020-03-03 15:14, clime a écrit :
On Tue, 3 Mar 2020 at 09:22, Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> wrote:

Le 2020-03-02 14:45, clime a écrit :
> On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> Le 2020-03-01 02:31, clime a écrit :
>> > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
>> > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> >>
>> >> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
>>
>> >> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
>> >> detached file state means that fedpkg local (or checking out git state
>> >> and building in mock or copr or OBS or via plain rpmbuild -bs) will
>> >> give you the same result as launching fedpkg build.
>> >
>> > Well, I believe it doesn't. You run:
>> >
>> > 1) fedpkg local -> produces <somepkg>-1.0-1.fc32 (1 in release because
>> > you haven't built that package before)
>> > 2) fedpkg build
>>
>> At that point state is undefined till the build succeeds or not. If
>> the
>> build succeeds, the buildsystem will write back a new state. Let’s
>> assume it succeeds.
>
> It's undefined if you add more elements to the equation than necessary
> (i.e. build system), otherwise it would be well-defined in this case.
>
>>
>> > 3) vim <somepkg>.spec and do some change in %description
>> > 4) fedpkg commit -m "description improvement"
>> > 5) fedpkg local -> produces <somepkg>-1.0-1.fc32
>> > 6) fedpkg push -> error because build system pushed meanwhile
>>
>> Yes, here the packager notices something else has been going on, and
>> he
>> needs to merge or rebase. He’d have the same effect if another
>> packager
>> had been doing stuff on the package, or a mass rebuild had been going
>> on. That’s the distributed decentralized aspect of git, except here
>> the
>> packager collided with himself by starting two work threads in
>> parallel
>> (one buildsys-side, one local).
>
> The problem is that you launched some process and you need to wait
> until it finishes, normally you don't need to anything like that when
> working with git.

But fedpkg build is a release to production process. It’s not a dev
staging process. In release processes, actually doing the release is not
an inconvenient optional check.

Well, you could have a situation when somebody wants to immediately
continue working after making a release. Probably rare but could
happen and if build time of a package is long (libreOffice/firefox),
this could hit you as an inconvenience. Or do you want to push-back
immediately after srpm build when you don't yet know whether the build
will succeed? That wasn't clear to me before.

Either you lock the centralized branch while the build is ongoing or you fail the build if someone pushes to the centralized branch before the end of the build.

That does not stop packagers from preparing the next stage in a local branch, only changing the state of the centralized branch at the same time the build process is changing it (two conflicting release state changes, option 1: buildsystem wins, option 2, packager wins, can’t have an heisenstate where things are both released and not released).

I am not suggesting to use raw git commit messages for the changelog
but instead content of annotated tags which can be initially
prepopulated by commit messages but can be then edited to any extent
and even the way the edit window for annotated tag is prepopulated
might be configurable (to .e.g. load content from a file in which case
you would probably skip the editing part). And I see the annotated
tags as the actual releases.

The only actual release is the package built in koji. So, no matter what mechanism you use git side: – you must represent the real state of package builds and not a git-only fiction → that means a form of buildsys write-back because builds can and will fail – you must produce something packagers can also build in mock or copr or OBS or whatever → that means checkout-ing changelog data in a form that can be read by rpmbuild -bs
  → ie a file not git metadata
→ with the associated conflict risk if multiple changes occur between checkouts

You can not avoid a buildsys merge-back when doing production builds.

Merge backs by build system can be avoided, however. Why do you think
they can't be avoided?

Because they’re the real state rpm changelogs records. Because that’s what people use rpm changelogs for. Something broke, what is the affected packaged, what where the released package states since last time it worked.

There is the case of mass rebuilds but this is pretty much a one-shot
event

Mass rebuilds are not an exception, they’re becoming the norm. Every SIG that deals with modern software released as a huge number of interlinked components needs to perform SIG-level mass rebuilds all the time (directly in rawhide, in a side tag, whatever). koshei can now autobuild all dependent packages when one of their requirements changed. That’s where the project is going and has been going for several years.

All the modularity efforts in the past years have been justified by the need to find a way to mass build things.

Regards,

--
Nicolas Mailhot
_______________________________________________
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