Hey jb, On 11/09/2011 04:16 PM, jb wrote: > Hi. > > The move to git and KDE servers is now functional, and I think we need to > agree on how we integrate new developers, and what are the rules to join / > contribute to Kdenlive. > > First, developers need to understand and comply to the git workflow (which > branch should be used for what, ...), Alberto will probably write something > about it in the next days. > > > 1) Getting a developer account > > I am not very sure about that, but my first idea was to make it rather easy to > get a developer account, maybe request a quick presentation on the mailing > list unless the contributor is already known in one way or another. > > New developers get developer access on the git repo and a developer access on > the Mantis bug tracker. > > If that is not working, we can change it to a more formal way: send x patches > before getting access... but my previous experience on KDE's repository where > a lot of people had write access was rather positive.
I agree to be rather liberal there. But, isn't it that way that KDE has to agree as well since a dev has access to all KDE repositories? (If I got this right.) > 2) Contribution and collaboration agreed Simon > How about that: > > When someone wants to work on a bug or a feature, the process is: > > - Assign a mantis issue to yourself (create a new ticket if bug or feature > does not yet exist in mantis). That way, we can keep an eye on who's doing > what in the project. > > - If the feature involves important changes to Kdenlive or can change the > way > users work with Kdenlive, post a mail on the devel mailing list so that we can > discuss about the implementation and consequences. > > - Work in your branch and request comments / review if you are unsure about > your work > > - Merge to next for review / testing > > - When one of the project maintainer says it's ok, merge to head. > > Of course, this is not required for normal / simple bug fixing which can be > committed to master. > > If a developer does not follow the rules and repeatedly breaks the code or > introduces too much bugs, we revoke his git developer access and request him > to send patches for his contributions. > > New contributors can also send patches to the mailing list, and we are also > looking at KDE's reviewbord system which allows to send patches. > > When we agree on something, I will set up a web page explaining how to > contribute / join Kdenlive, so your comments are welcome. > > regards > jb ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
