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. 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 * changes in okular APIs can be more easily be reflected in the touch app (synchronized development) * 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 * 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) * it is the least amount of work to get the benefits desired (not handling multiple branches, keeping packaging and hacking simplified, etc) 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) * 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. cheers ... -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
