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

[Albert Astals Cid]

El Dilluns, 1 d'octubre de 2012, a les 00:35:36, Albert Astals Cid va 
escriure:
> 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".

After discussing with Aaron and Marco it seems I had a wrong perception of 
what really happened and they have indeed communicated as soon as they had 
something that was just a barebones app (which i thought it was more finished 
due to my unhability to build the code).

Hence I am publicly retracting myself from saying they did not communicate 
enough.

Sorry for the wrongness, the wrongness was on my side and not in theirs :D

Cheers,
  Albert

> 
> 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 ...
> 
> _______________________________________________
> Okular-devel mailing list
> Okular-devel at kde.org
> https://mail.kde.org/mailman/listinfo/okular-devel