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

[Lydia Pintscher]

On Mon, Jul 12, 2010 at 22:35, Jeremy Whiting <jpwhiting at kde.org> wrote:
> Lydia,
>
> Good work on this list.  Looks like we've got our work cut out for us, but
> we've got a plan so that's excellent.
>
> On Mon, Jul 12, 2010 at 1:27 PM, Lydia Pintscher <lydia at kde.org> wrote:
>>
>> 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
>
> Sorry I missed the BoF but how does allowing offline commits lead to
> community splitting?

Heh yea sorry that isn't completely clear.
The fear goes like this: Everyone has ideas for their great little
project. They commits in their own little repo and don't share it.
Missing communication about who is doing what leads to wasted efforts
and social problems. -> the community isn't as tight-knit as it was
before anymore.

>> - 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
>
> Looks/sounds good to me, maybe we should put this list on the wiki somewhere
> and we can put our name and/or a link next to each when we blog about the
> items?

Sounds like a good plan. Can you do that?


Cheers
Lydia

-- 
Lydia Pintscher
Amarok community manager
kde.org - amarok.kde.org - kubuntu.org
claimid.com/nightrose