New module: KPkPass

[Volker Krause]

On Saturday, 24 March 2018 20:54:54 CEST Ben Cooksley wrote:
> On Sun, Mar 25, 2018 at 12:15 AM, Volker Krause <vkrause at kde.org> wrote:
> > 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?
> 
> Hi Volker,
> 
> I would say the original proposal (of it starting off in KDE PIM then
> transferring over to Frameworks when the time comes) should be more
> than fine.

Great! So how do we get this done? 

I can think of the following steps:
(1) sysadmin ticket for the move from playground (or does this need to go 
through the kdereview cycle despite being essentially a move from kdepim-
addons code?), and for being added to the CI
(2) ??? for the new module to be added to the list of application release 
modules
(3) update module dependencies for kdepim-addons to depend on this once (1) is 
done
(4) once (3) is done, merge the patch that ports kdepim-addons to the external 
module

There are no translations in this, so nothing to do in this area I think.

Thanks,
Volker

> While packagers will have some versioning issues to deal with, this is
> essentially a solved problem as they've had to deal with it already
> for KHolidays)
> 
> Cheers,
> Ben
> 
> > 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20180328/f1d264c7/attachment.sig>