[Okular-devel] merging the mart/okularActive branch into master
Marco Martin
notmart at gmail.com
Mon Oct 1 11:32:36 UTC 2012
On Monday 01 October 2012, Albert Astals Cid wrote:
> When something is merged into okular master I am taking a the
> responsability as maintainer, and to be honest i can't even build Marco's
> branch at the moment in my regular KDE development system, feels a bit
> adventureus to me to commit that much.
it requires a small 48k library that at the moment resides in the plasma-
mobile repo.
that's not optimal, but at the moment i can't think of a better place for it
(could be own repo, but wouldn't make it any easier to build i think)
with frameworks it will probably be all in a single plasma frameworks place.
the need for this library is quite important, because removes quite a lot of
boilerplate needed to do an app with qml only ui, that's quite too easy to get
it wrong
> > * if someone wants to roll a Plasma Active based product release on a
> > schedule that conflicts with okular release schedules, that could be an
> > issue (branches essentially fix this issue; and really, it is preferable
> > to always take the latest stable release rather than some random
> > snapshot even if the touch app was in a separate repo)
> > * more code in one repository (not really sure that matters in this case,
> > but trying to list all issues i can think of :)
> >
> > those are the pro's/con's as i see them. please add / subtract as you see
> > fit and then come up with a decision as the maintainer of okular. i
> > really don't want this to become a discussion where each side asks
> > questions of the other with increasingly clever debate ;) i just want an
> > answer to "what should we do with that branch".
> >
> > i've shared my ideas, and explained my thinking above, and simply need
> > your decision as maintainer so i can do what ever is needed to make it
> > happen.
>
> My opinion was quite clear when Marco came with the "Okular Active" code
> back then, put it in a separate repo.
there probably were a misunderstanding, i didn't have a clear idea where that
should have gone (I still not completely do ;)
> But you want an answer to end the discussion so here it comes:
> * When I add up the pros and cons i end up with a number that is quite
> close to zero.
> * To me this means invoking the "the one that code is the one that
> decides" rule.
> - Marco says he doesn't have a strong opinion on this.
a topic i have a strong one however, is the effort not being isolated, what i
would really want is this app to be well integrated in the okulat community,
if it has something done in a wrong way technically, it should be fixed, but i
would like to end up with something that's widely accepted by the okular
community.
not disliked for some technical reason (that can be fixed;) nor ignored as
"not my problem"
the latter is perfectly legitimate (not feeling the need for it) if that's the
case there should be a more indepth explanation from my part why i think it's
very important (at least the qml components, since they would be the public
api in which any qml ui would use okular), but then yeah, we can move it
elsewhere ;)
> - You are the other one that has done coding on the active branch and you
> want it merged in master
>
> So so let's see the patch in reviewboard to merge this into master and
> discuss over hard facts :-)
here ;)
https://git.reviewboard.kde.org/r/106666/
Cheers,
Marco Martin
More information about the Okular-devel
mailing list