El dijous, 17 de març de 2016, a les 0:18:53 CET, Luigi Toscano va escriure: > Luigi Toscano ha scritto: > > Luigi Toscano ha scritto: > >> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote: > >>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote: > >>>>> Let me cut right to the chase, do you want to maintain it? Does it > >>>>> need > >>>>> to > >>>>> be in Plasma? > >>>> > >>>> Yes, I can maintain it. In fact many features come from components I > >>>> already control. > >>>> > >>>>> You're right that Plasma devs don't seem to want it, I thought my > >>>>> initial > >>>>> email made that pretty clear. We do think that disconnected systems > >>>>> are > >>>>> rather a fringe case, and that our time and effort is better spent on > >>>>> other > >>>>> things. > >>>> > >>>> Then the question still holds: with a maintainer, does it have a place > >>>> in > >>>> Plasma? I'm not talking about an hypothetical time and effort for > >>>> maintaining this offline use case (which will continue to be 0) but in > >>>> the > >>>> light of the statement above. In other words, if the question mark in > >>>> the > >>>> subject is real or rhetorical. > >>>> I'm ready for both possible outcomes. > >>> > >>> Ah OK, sorry for misunderstanding it. > >>> > >>> I think there are the following options: > >>> > >>> 1) keeping it in Plasma with maintainer > >>> 2) keeping it outside of Plasma with maintainer > >>> 3) moving it to unmaintained (that's basically killing it) > >>> 4) keeping the status quo (not wanted) > >>> > >>> My personal preference would be an optional component (hence Extragear), > >>> since I think that the vast majority of users has web access, so > >>> khelpcenter isn't necessary and only adds to our maintainance burden > >>> without much gain in those cases. > >> > >> My offer stands and we can rule out 4) and 3). > >> Note that 2) could also mean a move to Applications (from your point of > >> view it does not matter too much). > >> The case 1) shouldn't add maintenance anyway as the maintainer is > >> identified.>> > >>> If we can move from 4) to 1) (so status quo but with maintainer), that > >>> would already be an improvement of course. > >>> > >>> The question mark was honest, we haven't made a decision on it, but > >>> different people do have expressed a preference for not shipping it (as > >>> or > >>> by default in Plasma releases). We may have missed important points, and > >>> we > >>> don't want to just kick things out unilaterally. > >> > >> I think we can leave some time for other people to comment. The shortest > >> deadline of all possibilities is the one for moving into Applications, > >> and > >> there are still 8 days before the dependency freeze and two weeks before > >> the branch. > > > > Any other comment from anyone else? > > I think I made up my mind. If no one else objects further, I officially ask > the release team (in CC) if it is possible to accept khelpcenter as part of > Applications for the upcoming release 16.04, module "applications". No > dependency changes are planned for the current master branch khelpcenter for > now. > > We will have a bit of overlap for a while (khelpcenter/Plasma5.6 vs > khelpcenter/Applications16.04), but the version number from Applications is > higher, so it shouldn't be a problem for packagers (they already handled the > more complicated khelpcenter/kde-runtime vs khelpcenter/Plasma). > > If this is accepted, I will manage the various tickets with sysadmins (and > at least move the translations myself).
No objections from my side, please get a decision+moved tuesday the latest. Cheers, Albert > > Ciao _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel