On Monday 31 January 2011, Andreas Pakulat wrote: > Hi, > > something that hasn't been written down as far as I can see (if I > overlooked it, please point me to it) is what the policy on kdelibs is > to be now wrt. merging vs. cherry-picking of changes in branches and > master? > > Andreas
Not replying to any particular response in this thread... I don't know whether I missed something, if so, please let me know. I asked two weeks ago (http://lists.kde.org/?t=129546074300005&r=1&w=2) whether there is a commit/merge/push workflow defined for working on kdelibs etc. This is what I got as response: On Wednesday 19 January 2011, Ian Monroe wrote: > > Can somebody please add a simple step-by-step howto, what I have to do > > with identity.kde.org, projects.kde.org and git.kde.org, how the git > > push/merge/branching policy is for KDE, etc. If there are existing blog > > articles about this, please add links to them in a good visible place. > > There is no push/merge/branching policy for KDE. Different projects > will likely do their own thing. For the time being its just the > SVN-style development translated to Git. This looks to me like "do what you want, there is no policy". Now I see many people here arguing about things like cherry-picking and merging to 4.6 first and then merging or whatever. Do we have a policy in the meantime ? Where is it ? If not, this means I'm free to do what I want ? Like, just pulling and pushing every single commit ? IOW, how am I supposed to use git * for committing a trivial change to master/trunk * for committing a bugfix to a stable branch * for committing something non-trivial, but not really big ? Alex
