[Kde-scm-interest] akademy move to git bof summary

[Lydia Pintscher]

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