[Okular-devel] merging the mart/okularActive branch into master

[Albert Astals Cid]

TLDR, skip to the end for the conclusion

El Diumenge, 30 de setembre de 2012, a les 19:20:00, Aaron J. Seigo va 
escriure:
> On Sunday, September 30, 2012 18:44:25 Albert Astals Cid wrote:
> > > (for many application won't be even
> > > possible) having separate repos one for each mobile application becomes
> > > pretty quickly a mess.
> > 
> > Why? we have separete repos for almost all our apps nowadays. And from
> > what
> > i can tell "Okular Active" as you call it is just a that, a new app using
> > the okularcore library.
> 
> the desktop app is not done this way.

True, but understandable due to the fact that the the desktop app is the main 
reason okularcore exists and that the people developing both is the same.

> but yes, the touch UI can go into its own repository. it's obviously not a
> question of "can we". all choices are possible here (leave it in a branch
> and continuously merge master; break it out into its own repository; shove
> it into plasma-mobile repo; merge it into okular master).
> 
> so what are the pro's and con's? imho, keeping it in okular pro's are:
> 
> * keeps the okular usage in one place, which makes both hacking and
> packaging easier

Okular usage is already spread, there is a odp plugin in calligra, and a 
mobipocket plugin in kdegraphics-mobipocket.

Actually i do think that having a different repo would count as a "pro" since 
it would guarantee the libraries are properly usable for someone that wants to 
do an application (up to now we only have document format plugins) with only 
access to the installed headers.

> * changes in okular APIs can be more easily be reflected in the touch app
> (synchronized development)

okularcore APIs are quite stable, we only recently broke ABI for the first 
time since 2004. Actually the other day i was planning to remove a bool from a 
function we don't use in the desktop client anymore and didn't because Marco's 
code is using it.

> * encourages awareness of the QML support within the okular developers
> * gets those working on the touch based app looking more into the rest of
> okular rather than simply treating it as a distant dependency

Collaboration is a cultural issue, doesn't matter where the code resides.

And to be honest, the collaboration started quite bad with you guys coming to 
this list with an almost finished product and saying "Hi, this is Okular 
Active".

As I've already communicated back then via IRC to you both I am sure the 
Okular community would have welcome knowing that you were working on that code 
before it was "done" so if anyone was interested in helping or shaping the 
project could have done so.

> * with commits being in one place, there's a greater sense of vibrancy in
> okular development (one big fire instead of lots of little ones)

That'd be cool, but haven't seem much of this fire in the list, sadly :-/ In 
fact you aren't even subscribed :D

> * it is the least amount of work to get the benefits desired (not handling
> multiple branches, keeping packaging and hacking simplified, etc)

Is it really? i am not that convinced.

> 
> con's:
> 
> * if the okular project is not interested in the touch app, or feels that
> plasma active is not a useful target, then it could be an unwelcome addition
> * if the touch app becomes unmaintained, then its one more bit of rotting
> code in the okular repo (though this is easily handled by removing it)

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.

> * 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.

Now you send an email with subject "merging into master" as if that was always 
the plan and making me look as the bad guy for saying otherwise.

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.
  - 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 :-)

Cheers,
  Albert

> 
> cheers ...