Re: Please wait a bit longer before calling for a vote
Hi Am 29.11.19 um 14:46 schrieb Sam Hartman: >> "Simon" == Simon Richter writes: > > Simon> While I generally agree with Sam here that it is rather > Simon> disingenious to add a new option right at the end of the > Simon> discussion period, I think that having something proposed by > Simon> the systemd maintainers on the ballot will be worthwhile > Simon> because they have one of the best vantage points to see > Simon> future points of contention and whether the GR is likely to > Simon> guide us through them. > > Martin Pit has publically stated he's one of the people I reached out > to in developing my proposals. > As I understand, he's been active in maintaining systemd both in Ubuntu and > Debain. > I was and am very grateful for Martin stepping in to engange in those discussions, even if he is not that active anymore in Debian/systemd since he moved to RedHat. When the initial options for the ballot were proposed, I contacted Martin privately, that I was not happy with the existing options (I think that was roughly two weeks ago). I did not follow debian-vote, because I find those Debian politics very emotionally draining. I was hoping given my feedback, that Martin would engage in further discussions to refine the proposals. This apparently did not happen and was probably too naive from me. During this week I was contacted via IRC by people who were concerned about the state of the existing options, as they didn't feel represented there. While I was trying to get a text together during the week, I failed to do so, for which I apologize. So I asked Ansgar, if we could ask you, Sam, for one week delay. The reason being, that I did *not* want to propose an option the last minute. I completely agree with Simon here, this didn't feel right. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Please wait a bit longer before calling for a vote
Hello all, Sam Hartman [2019-11-29 8:46 -0500]: > > "Simon" == Simon Richter writes: > > Simon> While I generally agree with Sam here that it is rather > Simon> disingenious to add a new option right at the end of the > Simon> discussion period, I think that having something proposed by > Simon> the systemd maintainers on the ballot will be worthwhile > Simon> because they have one of the best vantage points to see > Simon> future points of contention and whether the GR is likely to > Simon> guide us through them. > > Martin Pit has publically stated he's one of the people I reached out > to in developing my proposals. > As I understand, he's been active in maintaining systemd both in Ubuntu and > Debain. More like "had been active" -- I don't find much time any more to maintain systemd in Debian, I'm afraid. Mostly because of IRL/work things, not for reasons within Debian itself. Yes, I was part of that discussion from the beginning, but I haven't heard from Michael about this either, i. e. I don't know what he wants to propose. Martin
Re: Please wait a bit longer before calling for a vote
Hi Sam, On Fri, Nov 29, 2019 at 08:46:31AM -0500, Sam Hartman wrote: > Martin [Pitt] has publically stated he's one of the people I reached out > to in developing my proposals. > As I understand, he's been active in maintaining systemd both in Ubuntu and > Debain. Indeed, most of my interactions with systemd maintainers have been with either Michael or Martin. It might be helpful at this point to know the general direction of the planned amendment, even if the wording is not final. Simon
Re: Please wait a bit longer before calling for a vote
> "Simon" == Simon Richter writes: Simon> While I generally agree with Sam here that it is rather Simon> disingenious to add a new option right at the end of the Simon> discussion period, I think that having something proposed by Simon> the systemd maintainers on the ballot will be worthwhile Simon> because they have one of the best vantage points to see Simon> future points of contention and whether the GR is likely to Simon> guide us through them. Martin Pit has publically stated he's one of the people I reached out to in developing my proposals. As I understand, he's been active in maintaining systemd both in Ubuntu and Debain.
Re: Please wait a bit longer before calling for a vote
Hi, On Fri, Nov 29, 2019 at 01:22:37PM +, Holger Levsen wrote: > > I do not support delaying the CFV for an option that has not gained > > sponsors. > just sigh. > Michael, I'm very very likely to sponsor anything you have written so > far. Please publish something so it's on the table and Sam cannot argue > like he does. While I generally agree with Sam here that it is rather disingenious to add a new option right at the end of the discussion period, I think that having something proposed by the systemd maintainers on the ballot will be worthwhile because they have one of the best vantage points to see future points of contention and whether the GR is likely to guide us through them. So I'd also very likely sponsor such an amendment, even this late. Simon
Re: Please wait a bit longer before calling for a vote
On Fri, Nov 29, 2019 at 08:11:48AM -0500, Sam Hartman wrote: [...] > I do not support delaying the CFV for an option that has not gained sponsors. just sigh. Michael, I'm very very likely to sponsor anything you have written so far. Please publish something so it's on the table and Sam cannot argue like he does. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Please wait a bit longer before calling for a vote
> "Ansgar" == Ansgar writes: Ansgar> Hi, I would like to ask people to wait a bit longer before Ansgar> calling for a vote. Michael Biebl said he is looking into Ansgar> drafting an alternative, but has been too busy with work in Ansgar> the last few days. He would therefore like to have a bit Ansgar> more time to prepare. I'm sorry, but I've been trying to work with Michael for a number of months to get his input on these issues. He has told me that the problem is not me, but that even answering the question of why responding to the mails I have sent is too emotionally difficult to engage in. He's been aware that I'm considering this issue since September and has known that I planned to propose a GR since my September/October bits mail. Michael has been invited to engage in this process repeatedly, but has chosen not to do so. There's nothing wrong with that. We are all volunteers. However, when you choose to not engage with a discussion, you need to gracefully accept that you lose influence. Doing anything else means that you're trying to block the work of others in a very disrespectful manner. But there is a huge problem with trying to block forward motion at the last minute with a completely new option that no one has seen. In this instance, blocking on Michael would be implementing exactly one of the negative patterns Ian talks about in his proposal. As we've discussed before, there are two significant costs to waiting: * Many people have talked about the high costs of these discussions. I've seen comments to that effect on debian-devel and from multiple people on IRC. There have been a lot of emails in this discussion. Following this has been a significant cost for all of us. Dragging that out has costs. * Delaying the CFV runs into significant chance of having most of the vote be up against the holidays, making it harder for people to vote. Delaying the CFV into January leaves the discussion open way too long at least if you value the concerns raised about the cost of the discussion. Depending on how the discussion between Lucas and Ian goes, I can see delaying the CFV for a couple of days while they hammer out amendments. People who want to wait are free to rank further discussion above other options. You can still express your preferences among the existing options while ranking further discussion first. I do not support delaying the CFV for an option that has not gained sponsors. signature.asc Description: PGP signature
