On Wed, Jul 5, 2017 at 7:01 AM, Christian Mollekopf <[email protected]> wrote: >> This comes again from the diversity in view: for me the review, with all >> its limits, it's the baseline. >> As showed in the discussion, releasing from playground is not more >> complicated than other type of releases. > > Yes, I'm fine with that. I just wanted to make sure releasing from > playground doesn't require any exceptions but is regular procedure. > >> It's just when it becomes "too much" that >> people start asking "why not go for a proper review". It's not different in >> my >> opinion from new contributor submitting patches until someone see that >> it's "too much" and start asking "why don't you get a proper account". > > Essentially managing the system by applying some peer pressure to get > people out of playground. > Personally I don't find that necessary but it's a valid approach of > course.
Releasing from playground ad infinitum seems to have some disagreement. As was already pointed out, once the cost/benefit ratio becomes acceptable most devs will probably just go for review anyway. Playground becomes a disadvantage when you need a stable branch with l10n for example. Ultimately the cost is more on the review side I think, more than anything else anyway. If it wasn't for the review it'd be a matter of filing some paperwork to get the move done. There are two problems which seem to get ignored with reviews though and they ultimately play into the projects-arent-moving-to-kdereview . 1. Our manifesto establishes shared ownership of software licensed under an acceptable free software license and using our established practices. Yet we do not verify or enforce this up until the project gets to kdereview. At which point it may well have had 50 distinct contributors claiming copyright under the GPLv1 making relicensing a right hassle. 2. While kdereview certainly establishes a baseline quality, unless the software dies right after review or gets 0 feature development (both of which aren't good I'd say) the longer it exists the shittier it gets as the time since review keeps growing. I guess the question is really: What is playground? Is it us, KDE, writing new software? or is it Someone else writing new software? And as a consequence of that: Why do we have this hurdle to get out of playground? We do not review the maintenance of the baseline we established during review. I am guessing we do not re-review because the expectation is that the authors are able to follow our community policies after the initial review. Fair assumption for sure. BUT if we, KDE, are to be trusted to maintain the baseline without re-review, then why are we not trusted to write new software with that same baseline? For new stuff that comes in via incubation the review is certainly sound. If nothing else it asserts our policies on the pre-existing code base. If the authors continue to implement the community policies after review, is assumed but not verified, they are now KDE, so they are trusted to maintain this level. Food for thought. (to make this clear: I am not necessarily saying kdereview as a step needs to go, I am saying we are turning a blind eye to the fact that we take no measure to maintain review quality rendering the notion of reviews sem-moot, all the while our new and most vulnerable code sits there potentially incorrectly licensed) >From where I am standing we should have a stage before playground. Scratch repos if you will (although those are slated for deprecation without replacement). This addresses the code-dumping github-like use case, no tickets, little overhead. If it doesn't work out you throw it away. This gives us an actual playground: "I need no translations, no CI, no nothing, I am prototyping here" (think pre-alpha). From there it can proceed to playground (alpha stage). This is automatically a submission for continuous(?) casual review. It is at this point under joint ownership so we ought to assert our policies hence the casual review. Once ready (as determined by the authors) it moves to frameworks/plasma/applications. I understand this is a bit of a hippie workflow, but think about it this way: the reason we don't just review playground is that it's potentially little to no code and/or heavily rotating code, neither of which makes it easy to do a review. If the software is out of initial protoyping we have code to review and it's far less rotating already (the degree of rotation matters little, as the assumption continues to be that once we assert our policies they will get continuously implemented by the author). At the same time this removes almost all the policy overhead of moving from playground to the final destination. The code is already reviewed, all it takes is a ticket to become a proper application. TLDR: instead of making people not get too comfortable in playground make them more likely to want to move to applications (by making that super easy) HS
