Re: License change

On 2007-05-10, Tuomo Valkonen <[email protected]> wrote:
>> The message will use elog, which is user configurable and some of our
>> users have it mail them the output. In one case, namely the paludis
>> package manager, elog messages get shown at the end of the complete
>> batch build. In every case, the user gets a log file with the messages
>> the package emitted.
>>
>> The use flags will have a (unsupported upstream) added to their
>> description.
>
> I don't think that's quite prominent enough. Also "unsupported 
> upstream" doesn't have quite right the connotation: it could
> be mistaken that the particular feature is not supported. 
> The words "upstream support void" would perhaps be more to the
> effect. There's also the problem of users getting instructions
> from elsewhere, and never reading the description, or the log.
> Therefore, the flags themselves should perhaps be prefixed
> "support-void"; cmp. "warranty void" stickers on devices. 
> (For FOSS there's no warranty, of course.)


Might I clarify, that the log (as a reminder) might be enough if
the options themselves already contain the information in condensed
form. The whole point of the "name policy" is that the user knows
what he's doing, and therefore must explicitly request for additional
features and old versions, and know that they're unsupported. If
the use downloaded the official tarball, it would automatically be
the latest. If he would then patch it with random patches from the
net, anyone who is not a semi-moron should know that the version
is unsupported. Distributions may provided "shortcuts" to applying
such patches, and they may provide old versions, but they should
still approximate the process the user would go through when patching
the official tarball, or obtaining an older one.

I think I will refine the "Ion soup" part to something like follows,
to avoid confusion:

    b) The standard non-significantly modified version must be
    provided by default. Options may, however, be provided to
    modify the program on the user's explicit request, when these
    options make it clear, that the modified version is no longer 
    supported by the author, and not considered the standard version.
    The version displayed by the program must be updated to mention
    the modifications and the unsupported nature.

Something like 'USE=ion3-supportvoid-xft' should do that, with
additional reminder in the log or wherever.
Likewise, old versions may be explicitly requested for. If not,
the installation should fail or ask whether the user really wants
to continue. The best way to do the old version check is probably
a "dead man switch" somewhere in the packages or tools. The crudest
form is packages that start complaining when they're more than 28
days old. A more refined form would have packages download a small
database of triples (package, upstream-version, checked-when),
updated in the distribution's repositories either automatically or
manually by the package maintainer. (Checking upstream version and
Setting the switch once a month should not be that much work. 
Package maintainer should pay at least that much attention.) Then,
the package or package maintenance tools would check whether the/a
package request to be complained when upstream-version does not
match, checked-when is too old, or this information is not available.
With package maintainer comind and going, such a _service_ would be
useful -- essential even -- in general. Users could also use it to
check whether the version provided of other packages by the 
distribution is too old to bother with -- which is too often the
case, maintainer MIA. 


-- 
Tuomo