RFC: Turning flag TINY into ACTIVEONLY, move Author to toplevel dir

[Friedrich W. H. Kossebau]

Am Dienstag, 19. Februar 2013, 11:55:39 schrieb Jaroslaw Staniek:
> On 18 February 2013 23:31, Friedrich W. H. Kossebau <kossebau at kde.org> 
wrote:
> > Am Montag, 18. Februar 2013, 10:17:35 schrieb Jaroslaw Staniek:
> >> Hi Friedrich, thanks for the effort and explanation.
> >> 
> >> Regarding the naming only: I think TINY is useful in general. It would
> >> be a starting point to alternative GUIs and apps that are not in the
> >> Active family but are have in certain aspects minimal or stipped-down
> >> functionality. So I'd like to effectively see general name (such as
> >> TINY) kept as it is.
> > 
> > What are you thinking exactly of? And we still could add that once those
> > alternative GUIs and apps pop up, no?
> > 
> > This sounds like preparing for hypothetical use cases, without concrete
> > examples (and thus defined needs). But there are schools which teach to
> > better avoid that, as it only adds unneeded complexity and will usually
> > not be fitting stuff that actually pops up. And life showed at least me
> > those schools are based on heuristics ;)
> 
> Well, KEXI_ONLY and KEXI_MOBILE is not hypothetical, we want to have
> that targets too, e.g. for Windows and/or BB10/Android builds.

"hypothetical" was slightly extreme and bad wording, I meant "maximally only 
planned, but not yet started", so unknown in the real needs.

> I don't know how to split the build targets now but the need is pretty
> clear to me.

Not to me :) Because, how does TINY relate to KEXI_ONLY and KEXI_MOBILE?
Problem here seems that the meaning of TINY is undefined (task: define all 
build parameters), so everyone might use that parameter for other purposes. 
Like has happened now with Calligra Active, where TINY was not really matching 
the usecase even (as it also limits the range of filters built, which surely 
is not wanted for CalligraActive, at least with the tablet version where the 
full set is wanted, just the UI should differ).

And as you said yourself the effective meaning of KEXI_ONLY and KEXI_MOBILE 
(how to split the build targets) is also yet to be defined. So any preparing 
for those needs is based on guessing, and thus should better delayed to when 
the needs are known, I argue.

Cheers
Friedrich