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