Heya :) We had a very good discussion about how to improve communication to the rest of the community about our move to git. In the last months we've honestly been rather bad with that every now and then. I've seen sentences like "You're stupid because you're using SVN" and that wasn't meant in a funny way in that conversation. That's obviously not the way to win the hearts of the rest of the community.
The way forward is to make it clear in our communication that git isn't perfect but brings us a huge amount of benefits. And at the same time make it clear that SVN isn't perfect for us either atm. During the bof we came up with a list of good and bad things that we need to talk about. = bad = - allows offline commits -> community splitting - move means / will mean work - move will cause disruption to workflow/projects/deadlines for a while -> pick the right time for the move to cause the least amount of disruption - steeper learning curve - repo management is needed (this was about allowing force push iirc - my notes say we need to ask sysadmin what the status of that is atm) - non-resumable checkout -> offer shipping DVD's / usb sticks = good = - enables a social workflow (for example linux kernel style development -> problem and opportunity to rethink our development model?) - lowers the barrier - increased 3rd party contributions (about x10 for Amarok I'd guess) - clearer patch flow (gitorious - need to figure it out for git.kde.org still) - occasional contribution gets easier - offline commits - separating stuff in branches is easier -> work on many different things simultaneously gets easier - checkout size - complete history = needs doing = - document the patch flow clearly - have and advertise a helpdesk like thing where people can go if they screw up they repo - especially in the first weeks/months - document the most simple way to work with git / how to work like in SVN - find more people to write rules files - keep pushing for continuing to "commit early, commit often" and public sharing of branches - make it clear that we will need to keep an eye on communicating what everyone is working on in their branch This is by no means an exhaustive list but one that should be a good start for the next weeks. I was thinking we should start with maybe short blog articles each about one of the points above and explaining it a bit more in detail. Anyone up for that? I'm happy to help with review and other tips but I'm not feeling comfortable to write those on my own. Cheers Lydia -- Lydia Pintscher Amarok community manager kde.org - amarok.kde.org - kubuntu.org claimid.com/nightrose _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
