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. 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. For some cultural context: Gerrit has its critics. Awhile back I believe that Isaara suggested burning it "in a huge fire". 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
