[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

On Fri, Dec 06, 2019 at 09:51:50PM +0100, Guillem Jover wrote:
> [ Sorry, resending signed this time around. :/ ]
> Hi!
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether this will be acceptable or not to the
> Secretary, and what would be the actual procedure to replace the existing
> option G with this one (as long as enough of the original sponsors are
> fine with it), as I've found the way the procedure was applied/interpreted
> to be rather confusing or perhaps not matching my memory of previous
> instances.
> The changes to the original G are:
>  - Addition of Principles section title.
>  - s/tradeoffs/trade-offs/g.
>  - Addition of Guidance section.
> I'm CCing all the previous sponsors explicitly, just in case.
> ----X<----
> Title: Reaffirm our commitment to support portability and multiple implementations
> Principles
> ~~~~~~~~~~
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> Guidance
> ~~~~~~~~
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> ----X<----
> Thanks,
> Guillem


best regards,
  Ricardo Mones 
  RTFM - "Read The Manual" (The 'F' is silent). Usually a very good 
  idea.                                             Bjarne Stroustrup

Attachment: signature.asc
Description: PGP signature

Reply to: