[RFC] Possible KView Maintainership

[Nicolas Goutte]

On Wednesday 26 October 2005 04:33, James Richard Tyrer wrote:
> Nicolas Goutte wrote:
> > On Monday 24 October 2005 18:06, James Richard Tyrer wrote:
> >> David Faure wrote:
> >>> On Sunday 23 October 2005 00:14, James Richard Tyrer wrote:
> >>>> Yes, I know that there is a freeze on KDE-3.5 till version
> >>>> 3.5.0 is released.  Therefore, I was going to work on 3.4
> >>>> first.
> >>>
> >>> Doesn't make sense. 3.4 is even more frozen than 3.5 - it's so
> >>> frozen that it's dead :) There won't be more releases of
> >>> KDE-3.4.x, so it makes no sense to work on kview there. Do
> >>> bugfixing in 3.5 branch, and new developments in trunk.
> >>
> >> In the general case, what you say is true.  However, as NG
> >> correctly points out, fixing the UI issues (bugs) will require
> >> modification to the documentation and there is currently a
> >> pre-release freeze on documentation.
> >
> > No, the documentation freeze is not for pre-release. It will last for
> > the complete KDE 3.5 branch (as it is for all preceding branches,
> > including KDE 3.4.)
>
> This presents a very interesting problem that perhaps has not been
> considered before.  Clearly, if the menus to not conform to the current
> UI Guidelines, this is a bug.  But, the documentation documents the
> menus as they currently exist.  The bugs should not be fixed without
> changing the documentation and the documentation is frozen.

You can see it from another point of view.

The choice in that case is between:
- an application following the UI guideline
- an application having translated documentations

The KDE policy is currently to prefer having translated documentations.

>
> I do not offer a solution to this situation.



(...)
> > then you should better make a copy of branches/KDE/3.5/kdegraphics
> > (or parts of it) to a new directory in branches/work and work there.
> > Only when the changes will be in the KDE 3.5 branch, then you can
> > think about backporting them to KDE 3.4, if you find it useful.
>
> If the exact same changes are to be made to the KDE 3.4 BRANCH and the
> KDE 3.5 BRANCH, does it matter which is done first?

Sort of.

The older the branch the less it is tested. Problems in KDE 3.5.x can be 
probably found earlier (due to more testers) than on KDE 3.4.x. In case of 
errors, it also has less impact on users really wanting stable software.

>
> But, you correctly suggest that KView development work would probably be
> better done somewhere other than in the 3.4 or 3.5 branches.  So, yes, I
>   will put a copy of KView there to work on it.  Thanks for the suggestion.

I am just thinking: you would have also the choice of making it an extragear 
application, especially if you plan  to simplify it. (But then be careful 
than neither the program nor any library should have the same name than for 
the original KView.)

(If you choose to do that, either use the work branch or one of the playground 
modules (not sure which is best).)

Have a nice day!