Hi, the below request for adding a new module to KDE PIM for the 18.08 release resulted in some questions about the rules for new modules, as I ended up facing the following conflicting constraints:
(1) We do not do "direct-to-frameworks" releases, ie. new modules should be battle-tested elsewhere before moving to KF5. (2) We do not do releases from playground, and following that, no released module can depend on playground modules. (3) Module moves have to be avoided where possible, ie. they should only be done to fix stuff, not as a planned evolution of a module. Do all these rules actually exist, or are some of them myths? :) In particular (3) was new to me. If all three rules are valid, how do I solve the scenario outlined below then? Thanks! Volker On Sunday, 18 March 2018 09:55:27 CET Volker Krause wrote: > Hi, > > in order to make the travel/itinerary code started in kdepim-addons > accessible for the corresponding mobile app too, I'm currently moving the > shared parts to separate repos/modules. > > The first one ready to go is KPkPass (see kde:kpkpass.git), a library for > reading Apple Wallet pass files, the de facto standard file format for > mobile boarding passes. No rocket science in there, just parsing the file > (essentially a zip file containing a JSON file, message catalogs and image > assets) and making it consumable by Grantlee and QML for display. > > I'd suggest to include this in the next PIM release (after 18.04 branching > has been done), with the longer term goal to become a tier 2 framework once > it has been battle-tested as part of one or two PIM releases. This would > then become a dependency of kdepim-addons, for the pkpass messageviewer > plugin. > > I'm also working on a similar split for the itinerary data model and > extraction code (currently in scratch/vkrause/kitinerary). > > Regards, > Volker
signature.asc
Description: This is a digitally signed message part.
