Thanks for the input, but what's the conclusion here now? There's arguments for and against pretty much all the rules and approaches in here, so I'm a bit lost. Can I execute the original proposal?
On Monday, 19 March 2018 18:04:51 CET Volker Krause wrote: > 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.
