[ 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
Attachment:
signature.asc
Description: PGP signature