On 16 August 2015 at 11:14, David Faure <fa...@kde.org> wrote: > (*) I keep finding the "division" term a bit obscure, and I wonder if this > shouldn't be > called "product" instead. I.e. matching how we release things. Nowadays we > basically have 4 products (frameworks, plasma, applications, extragear?), > previously we had 2 (KDE SC 4, extragear). If this is what you had in mind > with divisions, then I suggest to call it product for clarity. > The reason why I think it's the same concept is that the one reason to have > different tracks is exactly because of different release schedules (e.g. > plasma > could be tested against KF5/Stable (last release) and KF5/Devel (more recent > code))
[Rambling naming bikeshed alert !] TLDR: We have a Marketing View and we have a Technical Build View and I think they are different enough to have different names and structures. How about we call 'division' something like 'build-group' or 'build-unit' instead? And while we're busy regrouping and renaming things, lets get rid of the application Modules... Longer: I like Product too, which is why I'm using it in the new TechBase KF5 Getting Started docs I started writing today [1] and especially [2], but I don't see it as being the same thing as 'division' here, and I think it exposes again a problem in our organisation and naming of Applications. My marketing-oriented view is we are organised as 3 Products: * KDE Frameworks * KDE Plasma * KDE Applications (We could add other products like 'KDE Infrastructure' and KDE Servers', but they're mostly internal). Within KDE Applications we then have a confusing mixture of Modules, Projects and standalone Applications with different porting status and release cycles: * Edu Module * Games Module * PIM Module * Playground Module * Review Module * Extragear Module * Calligra Suite * GCompris * etc... Now, some may argue that some of those are actually Products in their own right, e.g. Calligra and Extragear and GCompris, but they are Applications developed by the KDE Community within the KDE Infrastructure and adhering to the KDE Manifesto, they are all by definition KDE Applications, just with different development status or release cycles. 'division' appears slightly different to me, it is about grouping things into standalone build dependency units, so Calligra and GCompris do appear to belong at that level. OTOH, do we really want every repo in Extragear or Playground to have their own top-level 'division' just because they have different release cycles or different porting status or different version dependencies? Even the official KDE SC4 modules all have different porting status and thus build dependencies and thus conceivably different 'divisions'. That would just be too messy. I think how they get grouped into 'divisions' is always going to be different than the marketing Products and Modules. Alternative names that spring to mind are 'build-unit' or 'build-group'. Personally I think the whole Playground/Review/Applications/Extragear/Unmaintained module level split needs to go away and all Applications be considered equal, just with a different release status metadata tag based on the official lifecycle [3]. It's just reflecting the reality of the git-based split up of modules, different release cycles, death of a number of our sub-communities, and a more-focussed view on what makes up the workspace/applications split and their different release cycles. So, a proposal: we drop modules and extragear and playground and unmaintained altogether for organising our repos and paths and build process and instead just have Applications with a 'release-status' tag marking where they are in our official KDE Application Lifecycle [3]. A second 'release-cycle' tag could identify those that are to be included in the regular KDE Applications release cycle. We can still sort-of keep module, but now it's more a category tag, so all edu apps live under the path apps/edu/*. This could also remove some hassle when apps move around, their place in the namespace hierarchy and path doesn't change, just their release status tag. John. [1] https://techbase.kde.org/KF5/Getting_Started [2] https://techbase.kde.org/KF5/Getting_Started/Source_Code [3] https://techbase.kde.org/Policies/Application_Lifecycle _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
