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

[Jeremy Whiting]

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?


> - 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.orgstill)
> - 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?

Regards,
Jeremy


>
> --
> Lydia Pintscher
> Amarok community manager
> kde.org - amarok.kde.org - kubuntu.org
> claimid.com/nightrose
> _______________________________________________
> Kde-scm-interest mailing list
> Kde-scm-interest at kde.org
> https://mail.kde.org/mailman/listinfo/kde-scm-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100712/b98eaf29/attachment.htm