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
