Re: Rules to be approved as part of KDE Frameworks
- Original Message - On Tuesday, June 07, 2011 02:00:20 AM Aaron J. Seigo wrote: On Monday, June 6, 2011 19:41:15 Maksim Orlovich wrote: * all new features will be developed using the recommended git workflow (pending publication; Cornelius is working on that one); Those rules might seem like a strong departure from what we're used to. On the other hand, if you look at them closely, they are merely making explicit changes to our habits which already happened a while ago during the Qt 3 to Qt 4 port These two things don't really go well together now, do they? a documented git workflow is new, but needed. Yes, yes, yes. 100 %. We really need that. For git newbies (like me) and to avoid total chaos. And so that it stays possible to contribute to any KDE projects without having to figure out for each single project how they prefer to use git and branches etc. That's not what is happening. It's a workflow for the frameworks, the rest of KDE is invited to follow. So you still have to find out for each single project how they prefer to use git and branches. (afaics) Best, -- Tom Albers KDE Sysadmin
Re: Rules to be approved as part of KDE Frameworks
On Tuesday, June 07, 2011 10:11:59 AM Tom Albers wrote: - Original Message - ... a documented git workflow is new, but needed. Yes, yes, yes. 100 %. We really need that. For git newbies (like me) and to avoid total chaos. And so that it stays possible to contribute to any KDE projects without having to figure out for each single project how they prefer to use git and branches etc. That's not what is happening. It's a workflow for the frameworks, the rest of KDE is invited to follow. I'd make that the rest of KDE SC is strongly recommended to follow. For me, as having to work everywhere a bit from time to time, it is not manageble to figure out for each of the 50 or 100 repositories how these guys prefer to use git. This could be a thing which decides whether something wants to be in KDE SC or not. Alex
Rules to be approved as part of KDE Frameworks
Hello lists, disclaimer As, Sebas pointed out we've been meeting here to work on plans to improve our frameworks offering leading to the decision of leaving the current kdelibs model behind and prepare for a more modular suite named KDE Frameworks. If you didn't read his email yet, please do so before going back to this email. /disclaimer Don't be afraid, this email is likely to be shorter than the previous one. ;-) It might also be easier to understand the content of this email if you first read my previous email about the KDE Frameworks, although that's probably not mandatory. Here, we'll be dealing with what will be part of the KDE Frameworks, the answer is two fold really and depends if we're talking about a library or smaller code contributions. The content is mostly common sense, it is about trying to make explicit the good practices already in place in our community. This email is a draft of a future wiki page to complete our policies (or to be integrated in the existing policy pages). = Library Quality Criteria = Any library should meet the quality criteria to get KDE Frameworks stamps (as described in my previous email). The criteria in question are the following: * the code should follow our license policy; * the code should follow a consistent coding standard (it is encouraged to follow the current kdelibs standard throughout our frameworks but is not mandatory); * the framework should have a scope (no dumping ground); * the code should meet all the dependency criteria of its intended Tier and Framework Type; * the library should maintain binary compatibility until the next major release of KDE Frameworks; * the code should be unit tested with a sufficient coverage (the exact number still needs to be determined); * the developers of the library should comply to the code contribution quality criteria described below. = Code Contribution Quality Criteria = Since we can expect all the libraries, old and new, to get code contributions, the following rules will be in effect for the stamped frameworks: * the two apps rule still applies and should be considered like a minimum; * the added code should comply to the dependency policy for the library Tier and Framework Type; * the added code should fit in the library scope; * the contributor has to commit to maintaining the contributed code or find someone to take it over (social contract); * all new features will be developed using the recommended git workflow (pending publication; Cornelius is working on that one); * automated tests should be provided in the same commit as a fix; * commits meant to hit the master branch (bugfixes or merges) should contain a Reviewed by or REVIEW: in their commit log. = Conclusion = Those rules might seem like a strong departure from what we're used to. On the other hand, if you look at them closely, they are merely making explicit changes to our habits which already happened a while ago during the Qt 3 to Qt 4 port. We're trying here to make them systematic to get even better frameworks than before. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Rules to be approved as part of KDE Frameworks
* all new features will be developed using the recommended git workflow (pending publication; Cornelius is working on that one); Those rules might seem like a strong departure from what we're used to. On the other hand, if you look at them closely, they are merely making explicit changes to our habits which already happened a while ago during the Qt 3 to Qt 4 port These two things don't really go well together now, do they?
Re: Rules to be approved as part of KDE Frameworks
On Monday, June 6, 2011 19:41:15 Maksim Orlovich wrote: * all new features will be developed using the recommended git workflow (pending publication; Cornelius is working on that one); Those rules might seem like a strong departure from what we're used to. On the other hand, if you look at them closely, they are merely making explicit changes to our habits which already happened a while ago during the Qt 3 to Qt 4 port These two things don't really go well together now, do they? a documented git workflow is new, but needed. ditto with the tier/type concepts. the other items are as described in the second paragraph, however. is this problematic for you in some way? if so, can you clarify what that problem is so that we may understand and be able to address it? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
