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 <[email protected]> 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 > [email protected] > https://mail.kde.org/mailman/listinfo/kde-scm-interest >
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
