Re: Defining the future of the packager workflow in Fedora

[Petr Pisar]

On 2019-09-26, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
>  ○ Every changes to dist-git is done via pull-requests 
Pull requests are great for proposing your changes to foreign packages.
It does not make sense when maintaining the code. Either when doing
a mass changes like rebuilding all Perl packages against a new perl or
when pushing your own changes. It will become a bureaucracy that adds
a delay and complexity and spams you mailbox. Who is going to merge all
the requests? How do you automate it? We would need "koji watch-task"
for merging the pull requests. I will repeat it: pull requests are
great when you need a review. Otherwise it only consusmes resources.

I'm strongly against this.

>  ○ Pull-requests are automatically tested 
Nice. But i think this already happens.

>  ○ Every commit to dist-git (ie: PR merged) is automatically built in
> koji 
How do you want to implement waiting on propagating build root overrides?

>  ○ Every build in koji results automatically in an update in bodhi
How do I merge related updates into on if more packages must be
tested and delivered as one unit? That very often happens with the
overrides.

I smell automated side-tags that has never been implemented.

>  ○ Every update in bodhi is automatically tested 
This is already a reality.

>  ○ If the tests pass, the update is automatically pushed to the
> repository
>  
This also already happens.

-- Petr

A Gmane NNTP gatway test

[Petr Pisar]

This is a test message, please ignore it. (I'm trying to find out
why my last reply had mangled In-Reply-To header.)

-- Petr

Defining the future of the packager workflow in Fedora

[Guido Aulisi]

Il giorno ven, 27/09/2019 alle 08.31 +0000, Petr Pisar ha scritto:
>  On 2019-09-26, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
>  > ○ Every changes to dist-git is done via pull-requests
>  
>  Pull requests are great for proposing your changes to foreign
>  packages.
>  It does not make sense when maintaining the code. Either when doing
>  a mass changes like rebuilding all Perl packages against a new perl
>  or
>  when pushing your own changes. It will become a bureaucracy that adds
>  a delay and complexity and spams you mailbox. Who is going to merge
>  all
>  the requests? How do you automate it? We would need "koji watch-task"
>  for merging the pull requests. I will repeat it: pull requests are
>  great when you need a review. Otherwise it only consusmes resources.
>  
>  I'm strongly against this. 
I'm against too 100%

>  
>  > ○ Pull-requests are automatically tested
>  
>  Nice. But i think this already happens.
>  
>  > ○ Every commit to dist-git (ie: PR merged) is automatically built
>  > in koji
>  
>  How do you want to implement waiting on propagating build root
>  overrides? 
Good question

>  > ○ Every build in koji results automatically in an update in
> bodhi
>  
>  How do I merge related updates into on if more packages must be
>  tested and delivered as one unit? That very often happens with the
>  overrides. 
Another good question

>  I smell automated side-tags that has never been implemented.
>  
>  > ○ Every update in bodhi is automatically tested
>  
>  This is already a reality.
>  
>  > ○ If the tests pass, the update is automatically pushed to the
>  > repository
>  > 
>  This also already happens.
>  
>  -- Petr 
I agree with you completely, packaging can be quite time consuming and
complex, with mandatory PR it could become really impossible.

Guido
Ciao