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