Re: Debian Cloud Team delegation updates
On Thu, Jun 04, 2020 at 02:41:40AM +0200, Thomas Goirand wrote:
> >> We're afraid of conflict of interest. There's been multiple times where
> >> we saw it could happen, and by having the delegates not involved with a
> >> provider, we're hoping to reduce that risk.
> >
> > Can you cite a specific example? I cannot think of one.
>
> It's been tempting on nearly every meeting that the team bypasses the
> Debian policy, and customizes the images with software backported from
> testing, and still call that Debian stable. It took a lot of explanation
> from Steve at the time, to explain that this isn't what Debian is.
> Non-free cloud providers had (and to some extend, still have) a hard
> time understanding why we wouldn't simply push the very latest version
> of their tooling to Stable, or to our image.
None of that will change if the DPL delegates have commercial
relationships with cloud related companies. No DPL delegate has the
unilateral authority to override policy. Further, it's not as though
those discussions were split neatly along lines of those who have a
relationship with a cloud company and those who do not.
> Also, we want to make sure that we aren't giving a commercial advantage
> to a specific cloud provider. However, we're already doing this, by
> having a system which uploads our images directly to the 3 biggest
> providers, while the others have to manage it by themselves, and we
> still have no solution (yet) for OpenStack based providers. Hopefully
> that will be fixed when the image-finder gets useful, and we can build a
> script to automatically upload what's published, but we're not there yet.
Do you feel that any activity on the part of the DPL delegates lead to
this scenario? All past delegates have been bound by our restrictions
that forbid associations with commercial cloud entities.
> As per the delegation text:
>
> "the Delegates will:
> - Advocate for the adoption and advancement of Free Software cloud
> computing platforms and tools."
>
> How can the delegates push for more free software cloud computing
> platforms (and therefore, push for less non-free implementations like
> AWS, Azure, or GCE) if they are bound to an employer non-free cloud as
> primary business? This is a direct conflict of interest.
Keep in mind that all of the people doing work to support Debian on (at
least) AWS and Azure have been involved in Debian for far longer than
they've been involved in those services. Their involvement in Debian
and these other organizations may well prevent opportunities for
conflicts of interest, but that alone is not cause for disqualification.
Conflicts of interest arise all the time in professional activities, and
in most cases can be resolved simply by disclosing the conflicting
interests, or occasionally by recusing one's self from a decision making
process. With transparency, conflicts of interest do not need to be
blockers.
> > If *all* delegates were affiliated with a single cloud provider or other
> > similar entity, then I'd be more inclined to share your concern. As it
> > is, I think calling out that our restrictions on the delegations are
> > unusual in the broader context of DPL delegations is an interesting
> > point, and we should consider the possibility that we're excluding
> > people who might otherwise be well suited to this role.
>
> I've been the only person officially standing for an implementation of
> cloud computing which is free-software. As an alternative for cloud
> computing with completely closed software. And in all of the meetings.
Congratulations?
> In these meetings, I was happy that a few times, that we had Lucas and
> Steve steering the discussion on the correct path. They built solid
> foundations for establishing rules of what we allow to be called an
> "official Debian image". Without them (and with only me vouching for
> these ideas), it wouldn't be that clear in everyone minds. Probably we'd
> be publishing "official images" with lots of packages coming from
> backports, for example.
I assume you mean Luca. Either way, I don't think speculating about
what would "probably" have happened is at all helpful.
> If then we get all of the delegates being affiliated with a commercial
> clouds (even if it was 3 different providers), I would feel less
> comfortable. There's the danger that the team gets even more tempted to
> break these rules, because it'd be "more convenient" for example.
I don't think there's been a temptation to break any rules. To the
contrary, we as a team have engaged with the release team on multiple
occasions to figure out how we can ensure that cloud users have access
to up-to-date tools and SDKs for interfacing with cloud providers that
support all the features of that provider. We've reached pretty
reasonable agreements that put most of the technical work on us as a
team, and now we just need to do that work. It really hasn't been very
contentious at all.
> > Practically speaking, the cloud team delegates have little real power
> > and very few actual responsibilities. The possibility of abuse is
> > minimal. Transparency in our decision making processes should be more
> > than sufficient to address any potential concerns.
> >
> >>> We have Debian Developpers working for Ubuntu, Redhat, Prodigy, Kali in
> >>> the past and present, and it mostly goes fine.
> >>
> >> And? I don't see how this relates to the discussion.
> >
> > It relates directly. The very same conflicts of interest about which
> > you express concern apply in these cases as well.
>
> Mixing the role of a contributor with the one of a delegate isn't going
> to help as a point of argumentation. A contributor isn't one that takes
> decisions or speaks for the project. If you feel like the delegates
> don't need to take any decision, or speak for the project, then we don't
> need delegates at all.
Again, can you point to any specific decisions made by a DPL delegate
that might have turned out differently had the delegate had a commercial
interest in a specific cloud provider? All of the concerns you've cited
so far have been at the "contributor" level, rather than the "delegate"
level. At no point has a delegate used any authority to override the
decision of a contributor and enact the current situation.
> Plus there's all what Lucas just replied in this thread that I'm not
> going to repeat.
Again, I assume you mean Luca. I will respond to his message
separately.
noah
Reply to: