Thanks for the feedback! On Wed, Feb 17, 2016 at 11:39 AM, Pine W <[email protected]> wrote: > Hi Guillaume, > > Since I have a good case of insomnia and am reading emails between attempts > to sleep: > > As a "team practice" for remotes, I would suggest scheduling coffee breaks > just like people do in person, but chat on Hangouts.
That sounds like a good idea, I might try that. > Don't even try to assimilate 100% of IRC traffic. And if IRC distracts you > from Getting Things Done, minimize it and only look if pinged. I'm not trying to assimilate 100% (I do not think anybody can assimilate that much!). But just understanding which 1% I should assimilate is already a challenge at the moment. This sounds like a NP-complete problem (though I do not have the formal proof yet). > For some cultural context: Gerrit has its critics. Awhile back I believe > that Isaara suggested burning it "in a huge fire". That's an issue of me not being used to this way of working more than anything else (at least I think). It's always fun to see new ways of doing things. Makes me challenge what I've been doing for so long... > Please write the blog post that you mentioned! > > Glad to have you with us, > > Pine > > On Feb 17, 2016 01:50, "Guillaume Lederrey" <[email protected]> wrote: >> >> Hello team! >> >> I've been with you for 2 weeks. As Tomasz suggested, I might be the >> right moment to list what I have discovered so far. I'm trying to >> point out the difference I see from what I'm used to, not to judge >> (yet), I don't have enough context for that... Still I am biased by my >> previous experience and that will show up below... >> >> I need to unlearn a few things. It seems that last week, each and >> every decision I took has been challenged by someone (usually for good >> reasons). Things that I take for granted as "the right way (tm)" are >> actually done in a fairly different way here. Examples: >> >> >> == Distributed team == >> >> ** my belief ** >> It is hard to be part of a distributed team. >> >> ** what happens at WMF ** >> You've all been extremely welcoming! Having the chance to see you in >> person in SF in January definitely helps (it is a bit harder for me to >> find my way around the Ops team, probably in part because I have not >> had the chance to meet them in person). The fact that we also have >> kind of informal conversations (IRC, unmeeting, ...) helps to belong. >> It seems to me that you've made all the necessary effort to include >> me. >> >> ** comments ** >> I still have to make an effort to get in touch when I need to. I'm so >> used to coffee breaks where you take time to discuss whatever needs >> discussing. IRC feels more intrusive as it is a continuous flow, not a >> set time where you go have coffee and do the needful... I also need to >> learn to ignore IRC interruptions. It still feels that I might miss >> something important and that there is just too much information >> sometimes... >> >> >> == Versionning == >> >> **my belief ** >> anything deployed must have a version number >> >> ** what happens at WMF ** >> * deployments on labs are pretty much free-form, cherry pick whatever >> you want on puppetmaster >> * deployments on prod seems to have version numbers at least for >> mediawiki code, puppet code is deployed directly from production >> branch >> >> ** comments ** >> Having clear version numbers implies having a conscious decision of >> creating a version, potentially with the appropriate checks of the >> content of that version, additional testing. It allows to have a clear >> separation between creating a version and promoting it to production. >> Not having versions everywhere allows for more flexibility and puts >> responsibility of making the right choices more on the people than on >> the process. Probably a good thing if you have smart enough people >> (and WMF seems to have a pretty smart crowd). >> >> Having a shared git repository on deployment-puppetmaster scares the >> hell out of me! I'm so used to preparing anything I want to push >> locally and then just applying a specific tag / version... >> >> >> == Cherry-picking == >> >> ** my belief ** >> cherry-picking is bad and should be used only as a last resort solution >> >> ** what happens at WMF ** >> * cherry picking is the norm >> * this seems to be influenced by Gerrit, which promotes cherry picking >> and single commits patches >> >> ** comment ** >> I'm all for rewriting git history to make it more readable, to help >> tell the story of what is happening to the code. I think that branches >> and merges are a good tool for that. Cherry picking fixes from one >> branch to the next leaves a lot of opportunities to forget one. >> Merging helps tell the story of "those are all the fixes done on >> branch X, I've applied them on branch X+1". Also, I'm not a huge fan >> of gerrit idea of changes being a single commit. Having a coherent >> change split in multiple phases make sense to me (for example: 1) >> preliminary refactoring, 2) my actual work 3) some clean up I did >> along the way). I need to dig deeper into topic branchs and how they >> integrate with gerrit (yes, I am brand new to gerrit). >> >> It also seems that all this cherry picking creates much more >> flexibility (I can take any commit and apply it anywhere). Again, >> giving control back to the human and not to the tool. >> >> >> == Stupid code is good code == >> >> I need to write a blog post about this one, but like Kernighan said >> "Everyone knows that debugging is twice as hard as writing a program >> in the first place. So if you're as clever as you can be when you >> write it, how will you ever debug it?" [1]. Looking at our code >> (mainly puppet at the moment), I think there are quite a few places >> where we do the smart thing, when stupid would be sufficient. That's >> probably the cost of hiring smart people ... >> >> >> == A few random points == >> >> * We have an incredible amount of documentation. It is easy to read >> (I've been drawn into it and lost much time). It is also outdated in >> some place (documentation always is). >> * so many different ways to deploy (puppet, trebuchet, salt, manual stuff, >> ...) >> * I still have not found a global architecture schema (something like >> a high level component or deplyoment diagram). But I have never seen >> any company having those... >> >> >> [1]: https://en.wikiquote.org/wiki/Brian_Kernighan >> >> _______________________________________________ >> discovery mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/discovery > > > _______________________________________________ > discovery mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/discovery > _______________________________________________ discovery mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/discovery
