I will assume from the lack of response from this email that most are happy with the proposed workflow?
If not let me know soon or else I will continue with it as planned above. Regards, Nathan On Tue, Nov 10, 2015 at 8:15 PM, Nathan Woodrow <[email protected]> wrote: > Hi all, > > So I have been thinking about the QEP process, because yes the current > process is not good and way to slow for how we work. To streamline I have > talked to a few people and this is the notes so far. > > - Open for at least one week > - QEP process should be fast and evolve into a PR but also not cut back on > details. > - PR can also be opened at the same time - however not recommend if > something is still in planning stage and changing, or chance of rejection > e.g don't update all the code headers with MIT and then open a QEP because > it wouldn't happen. > - Code based QEPs require at least 2 +1's > - Requires +1 from maintainer of that area of code e.g Nyall for composer > work, Martin for rendering thread > - Project QEPs require majority PSC vote > - May be extended upon request (eg, i'm on holidays but have feedback) > - May be extended if required > - Others can assign themselves as interested e.g I might be interested in > Processing but can't comment on the code. Mainly just to provide feedback. > - If no maintainer for a area of code, requires at least 2 +1s from core > devs > > The tl;dr version: > > - Project QEP: PSC vote > - Code QEP: min +2 (+1 from maintainer plus +1 from other) > - Keep it semi formal but quick. > > The code maintainer for the different areas will need to be updated > however I'm sure we can handle that. > > How does that sound to everyone? > > I would like to make it fast but also give us time to review changes that > will affect the project. >
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
