[arch-dev-public] Todos for language specific rebuilds

[Christian Rebischke]

On Sat, Jan 11, 2020 at 09:57:42AM -0500, Dave Reisner wrote:
>    On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public
>    <[1]arch-dev-public at archlinux.org> wrote:
> 
>      Hi everybody,
>      I would like to propose that we create todos for rebuilds of
>      language
>      specific packages.
>      We had two major rebuilds in the last months: python3.8 and ruby2.7.
>      Can we agree that we create a todo before such rebuilds?
>      The advantages outweigh the disadvantages. We would gain:
> 
>    Hi,
>    I'm not sure I understand. Can you clearly state the problems we've
>    encountered due to not doing this? What downsides do you see to your
>    proposal? Can you think of any alternative solutions?

Hi Dave,
I am sorry. Looks like my actual proposal was a little bit unclear and
the whole discussion drifted to automation. This has been never my
intention.

I have no problem with the actual rebuild process and I don't care
if this happens manually or automated.
Actually I didn't want to point out specific package problems, but you
asked me, here they are.

My problem is that several packages dependending on ruby broke due to
the ruby2.7 rebuild:

* puppet5 broke due to missing ruby-sync in ruby2.7[1]
* puppet broke due to missing ruby-sync in ruby2.7[2]
* gitlab has problems with its API after ruby2.7 rebuild[3]

Furthermore multiple packages are throwing deprecation warnings now:

* gitlab[4]
* puppet5/puppet [1][2]
* vagrant has issues with the ruby2.7 rebuild[5]

Big thanks to Anatol for reporting several of these issues upstream and
fixing packages. I really appreciate his work.

The rebuild process itself is totally fine for me.
I just wanted to point out, that we should have a defined process for
rebuilds. Either in form of todos or in form of more communication on
a-d-p like "We are going to push all ruby rebuilds from [testing] to
[community] on date X. Make sure it's tested, if you encounter any
problems, speak with A, B or C or response directly in this thread".


>      * More people help rebuilding the packages.
> 
>    Solving the wrong problem, IMO. This is largely toil and should be
>    automated away. Foutrelis already has such a system that we've used for
>    rebuilds in the past. We could/should instead work towards making this
>    more generally available on the build machines.

I agree.

> 
>      * Every maintainer gets informed about the rebuild.
> 
>    As a maintainer, I don't care that you're rebuilding my package to keep
>    up with library changes. Rather, I'm thankful to whomever did this for
>    me.
>    Why would a language rebuild differ from any other soname bump?

I mostly agree, still would be nice to get a notification.

> 
>      * Maintainers have the possibility to test the packages.
> 
>    Why is this not currently possible? Couldn't we just use testing prior
>    to pushing out to the repos (something we've done in the past and
>    continue to do)? What about packages which aren't using the lowlevel
>    API and are simply interpreted code. Those don't get rebuilt, but
>    they're potentially impacted by the language version bump. They'll
>    never be called out on a rebuild lost because we generate those based
>    on ELF dependencies.
>    dR
> 

[testing] has been used and I wanted to test my packages, but the push
from [testing] to [community] happened before my scheduled date for
this. I just say that it would be nice if we have a defined process for
rebuilds with specifying a deadline for tests.

My hope is that this mail makes my intention clear now. The "proposal"
is just a spawn point for a discussion around a defined process for
rebuilds to prevent not working packages in the future.

Arch Linux is known for bleeding edge software _and_ stability, let's
keep it this way.

[1] https://bugs.archlinux.org/task/65106
[2] https://bugs.archlinux.org/task/65107
[3] https://bugs.archlinux.org/task/65097
[4] https://bugs.archlinux.org/task/64887#comment185125
[5] https://github.com/hashicorp/vagrant/issues/11290

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20200113/abc817a7/attachment.sig>