elections: Add Peter Delevoryas to rollcall

[williamspatrick]

@peterdelevoryas did not qualify using our current tools because his contributions are outside of Gerrit. In 2022H1, Peter did significant contributions to upstream QEMU for Aspeed support that is useful to all companies. I've filtered out any machine-specific commits in this list:

$ git log --author="Peter Delevoryas" --after="December 31, 2021" --before="July 1, 2022" --oneline
55c57023b7 hw/misc/aspeed: Add PECI controller
1c5d909f88 hw/i2c/aspeed: Add new-registers DMA slave mode RX support
0c0f1bee6a hw/i2c/aspeed: Fix MASTER_EN missing error message
b582b7a191 hw/i2c/aspeed: Fix DMA len write-enable bit handling
ceb3ff0e80 hw/i2c/aspeed: Fix R_I2CD_FUN_CTRL reference
85f0e0c3a1 aspeed: Remove use of qemu_get_cpu
80beb08567 aspeed: Map unimplemented devices in SoC memory
5bfcbda70d aspeed: Remove usage of sysbus_mmio_map
4dd9d55416 aspeed: Add memory property to Aspeed SoC
e37976d733 aspeed: Set CPU memory property explicitly
6827ff20b2 hw: aspeed: Init all UART's with serial devices
470253b6d0 hw: aspeed: Introduce common UART init function
94d10f4210 hw: aspeed: Ensure AST1030 respects uart-default
c5e1bdb9e2 hw: aspeed: Add uarts_num SoC attribute
ab5e86053d hw: aspeed: Add missing UART's
2ec063788e hw/gpio/aspeed_gpio: Fix QOM pin property

With this data in mind, I'd like to petition Peter be added to the roll-call for 2022H2's TOF elections.

[jebr224]

I am not opposed to this specific case.

However, I would be cautious about setting a precedent. Many openbmc contributors also contribute to other projects, of varying relevance. Trying to design a detailed method of accounting for this, that is also perceived as fair would be non-trivial.

[edtanous]

Trying to design a detailed method of accounting for this, that is also perceived as fair would be non-trivial.

Yep, this is exactly what we call out in the charter for the group, and while we hope to make it better over time, we understand there are gaps, and the appeal process Patrick did is the most fair way we can think of for the moment (everything can always been improved though if you have ideas).

In 2022H1, Peter did significant contributions

I do see he has many contributions to facebook/openbmc, and while not directly applicable, does make his input valuable in terms of differences in implementation, and how LF openbmc can improve. I see no problems adding him to rollcall.

👍

[peterdelevoryas]

I am not opposed to this specific case.

However, I would be cautious about setting a precedent. Many openbmc contributors also contribute to other projects, of varying relevance. Trying to design a detailed method of accounting for this, that is also perceived as fair would be non-trivial.

On second thought, if you guys prefer, we can wait and re-evaluate this in another 6 months. I'm expecting to contribute more to the actual LF OpenBMC codebase in the near future, up until now I've just been mostly focused on QEMU and FB OpenBMC.

I have opinions on how to steer QEMU to support OpenBMC, but at the moment, I don't really have that many opinions on steering the LF OpenBMC project itself, and like you say, it might not be a very good precedent to set.

[williamspatrick]

In some regards I opened this proactively because there are a number of other people who regularly contribute to untracked areas that did not petition last go-around for inclusion. I picked Peter since we both work for the same company and to, hopefully, give indication to all those other people that this is perfectly acceptable to request. Plus, as we discussed when we wrote the charter, if we don't know where those other contributions are it is hard for us to add them to the tooling.

If Peter were intending to join the TOF (which I don't think he is), he'd probably need to be able to better articulate opinions on steering the project, but I don't think mostly contributing to QEMU should preclude him (and others in similar situations) from being able to give voice to select their TOF representatives.

The TOF membership document explicitly says the following:

Currently, work on the following projects requires an explicit petition for recognition of ToF membership eligibility:

Linux
u-boot
QEMU
bitbake
open-embedded
Poky

We recognized at the time that we wrote it that Linux kernel and QEMU were two areas especially where people might specialize, and do work that is highly meaningful to the project overall, but the data was outside Gerrit.

[amboar]

Relevant section of the documentation: https://github.com/openbmc/docs/blob/master/tof/membership-and-voting.md#openbmc-development-community

[amboar]

The relevant election has come and gone so I believe we can close this.