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.
You're asked to autobump a “Release” field. You’re asked to automate a
changelog which is effectively a release changelog, not dev changelog
(the dev changelog lives in git, people want a good changelog in rpm
proper to track release not git history).
The *single* *only* reason good release numbers and good changelog
matter is because the result will be released to third parties. koshei,
or scratch builds, or whatever, do not care about those.
A normal git flow would lock the branch at release time to let the
release manager do his releasing (merge window closed in Linus’s terms).
That’s option 1 I gave you.
Alternatively, you can use option 2, the “I feel lucky” approach, let
everything open, and abort the release if merge-back failed. A packager
that changes his package before the production build is finished will
probably want it canceled anyway (what is the point of risking breaking
builds of other packages by pushing an unfinished package to the shared
koji buildroot)?
Either option does not stop the packager to do anything he wants in his
local branches. They just require him to merge/rebase when syncing with
the centralized master Fedora state. That’s a core element of git
architecture, be it in Fedora or elsewhere.
You can not avoid a buildsys merge-back when doing production builds.
The merge-back can be explicit and automatic (as I proposed), or you can
rely on informal meatware for it, but it will exist. Since the whole
point of the request is to lower dependence on meatware, why on hell
would you want to keep meatware as part of the whole process?
The only “cost” for the packager is to wait for his build to finish
before continuing to change the package (or merge/rebase). That’s not an
horrific cost. No one forced the packager to start a build before he was
ready. No one forced the packager to perform a production build instead
of a scratch build if he just wanted to check partial changes. If shit
happens, and he realizes before the build end something is not ok,
aborting the build on failed merge back is helping the packager.
Or am I missing something? “normally you don't need to anything like
that when working with git” is not a clear technical point.
Regards,
--
Nicolas Mailhot
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
