On Thu, May 28, 2015 at 03:21:14PM -0700, Joe Zeff wrote:
> What you're saying is, in effect, that boost 1.54 breaks backward
> compatibility and boost-terminal isn't going to get upgraded. Isn't
> it up to boost's maintainer to see to it that this doesn't become an
> issue? (Yes, we all know of cases where the maintainer either
> doesn't check properly or simply doesn't care, but it's my
> understanding that it's still part of their job.) One of the
The Debian constition includes a rule: "Nothing in this constitution
imposes an obligation on anyone to do work for the Project. A person
who does not want to do a task which has been delegated or assigned to
them does not need to do it. However, they must not actively work
against these rules and decisions properly made under them."
Of course, Fedora is not Debian, but really, this is a statement of
fundemental truth in a volunteer project rather than a legal ruling.
Some things to consider:
A. If someone packages software into Fedora, are they obligated to
maintain all current and future software which might depend on it
in perpetuity?
B. If so, should that maintainer be allowed to veto the addition of new
dependencies?
If you vote yes to both, get ready for it to be even harder to package
software for Fedora.
If you vote yes to A but no to B, any maintainer is signing up for an
infinite amount of work — I think most people would say "no thanks!".
In fact, I know for sure that the managers of many Red Hat employees
paid to work on Fedora packages would not agree to that — and, really,
how could I make them? And assuming I were given that power at RH,
who would wield it over volunteers?
I really can't think of a more reasonable approach than what we have:
best effort to deal with the _maintainers_ of dependent packages (and
sometimes fix them up as a proven packager), but no ultimate obligation.
Now, if we do get to a Fedora Rings model, it makes some sense to have
a bounded subset of these requirements:
A': If someone packages software into Ring N, they must also insure
that dependencies in Ring N and Ring N+1 are handled.
B': A maintainer of a Ring N package may veto the addition of a package
to Ring N or Ring N+1, unless the maintainer of the new package
agrees to co-maintain the base package and also help with A'.
But we don't have anything like that. So, we clean up by retiring those
dead packages.
> problems the OSS community keeps pointing to in commercial software
> is the way newer versions of programs fail to read or write files in
> formats that older versions understand, while bragging that their
> packages don't suffer from that fault. Has this changed, or is it
> simply a case of sloppy testing?
I think it's simply a case of overstating the claim. The "brag" is much
weaker than that. First, while software may bit-rot, format support is
rarely removed as a market driver as it is in commercial software.
Second, even if the software is no longer supported, you have the
source and can either attempt to built it yourself, or at least you can
look at the code and figure out the format without unreliable
reverse-engineering.
--
Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx>
Fedora Project Leader
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
