Core-chat-meeting-2018-08-09 09:31 < geertu> Welcome to today's Core Group Chat! 09:31 < geertu> Agenda: 09:31 < geertu> 1. Status Updates 09:31 < geertu> 2. Discussion Topics 09:31 < geertu> Topic 1. Status updates 09:31 < geertu> nA) What have we done since last time: 09:31 < geertu> Marek worked on U-Boot (USB VBUS and PHY on Gen2, HS400 on Gen3) and Linux 09:31 < geertu> (PCIe L0s/L1 handling on Gen3). 09:31 < geertu> Morimoto-san worked on PeriJect and Ebisu-4D export. 09:31 < geertu> Shimoda-san submitted PWM patches, and provided LTSI v4.14 snapshot 09:31 < geertu> feedback. 09:31 < geertu> Geert submmited v2 of R-Car gen3 OSC and RCLK improvements, reviewed lots 09:31 < geertu> of patches, enabled the Global Timer on Cortex-A9 MPCore SoCs, 09:31 < geertu> sub-maintained LSTI, and started looking into QEMU GPIO handling. 09:32 < geertu> B) What we plan to do till next time: 09:32 < geertu> Kaneko-san will test the M3-N CPUFreq upport. 09:32 < geertu> Marek will continue U-Boot SDHI HS400 support. 09:32 < geertu> Morimoto-san will ship Ebisu-4D boards. 09:32 < geertu> Shimoda-san will check the new LTSI v4.14 snapshot test results from the 09:32 < geertu> RVC test team, and will pave the way forward for IPMMU. 09:32 < geertu> Geert will review LTSI submissions during the merge window. 09:33 < geertu> C) Problems we have currently: 09:33 < geertu> Linus postponed v4.18 by one week, conflicting with Geert's holiday 09:33 < geertu> schedule. Hence next renesas-drivers release will be 09:33 < geertu> renesas-drivers-2018-08-21-v4.18. 09:33 < geertu> Anything I missed? 09:34 < geertu> s/submmited/submitted/ 09:35 < geertu> Lazy Summer (although it's a lot colder again)... 09:35 < Marex> geertu: well, HS400 in U-Boot is dragging on because the MMC maintainer is horribly slow to respond ... I might need to bypass him again at some point 09:35 < geertu> Marex: I'm sure you'll handle that fine 09:35 < horms> ... and for the same reasons my LTSI submission will be up to v4.18-rc8 rather than v4.18 09:36 < Marex> geertu: just like last time ... sadly ... we might be looking for a new mmc maintainer ;-) 09:36 < geertu> horms: Np, as v4.18 will (should) be released long before the LTSI merge window closes 09:36 < horms> not before the end of this week which is when I will be sending the next round of patches 09:36 < horms> before my holiday next week 09:37 < horms> otherwise it all falls to the last week of the merge window and the wheels could easily fall off at that point 09:37 < horms> I will follow-up with any patches added between v4.18-rc8 and v4.18 09:37 < geertu> horms: Postponing to the last week makes it more difficult for Intel to try to counter Renesas again ;-) 09:38 < horms> That is true 09:38 < geertu> (although they already know our plan anyway) 09:38 < geertu> Topic 2. Discussion Topics 09:38 < horms> But I'd rather de-risk other parts aspects of the project 09:39 < geertu> horms: Sure, thx a lot! 09:39 < geertu> morimoto: periject? 09:39 < wsa> what's with that Intel vs Renesas talk? 09:40 < horms> wsa: its a story from many years ago 09:40 < morimoto> geertu: sorry I didn't read text, but periject what ? 09:40 < horms> wsa: whereby there were two major contributors to LTSI. Renesas and Intel. And magically Intel had slightly more patches than Renesas 09:40 < geertu> wsa: Intel ended up backporting ca. 3 more patches than Renesas 09:41 < geertu> morimoto: Can we discuss periject? 09:41 < wsa> so they could claim #1 09:41 < wsa> ? 09:41 < horms> They also caused a hidious conflict with our work 09:41 < horms> wsa: yes, that is the theory 09:42 < morimoto> geertu: yes 09:42 < wsa> horms: bastards, I will only buy AMD cpus from now on! 09:42 < wsa> ;) 09:42 < horms> wsa: I got over it in time 09:43 < wsa> "There is no politics in open source" 09:44 < geertu> morimoto: The mic is yours! 09:44 < morimoto> thanks. 09:45 < morimoto> As you know I already posted periject on gitlab. you can try it. 09:45 < morimoto> I think "tool feature" is not yet 100% but almost OK 09:45 < geertu> morimoto: You have rebased the master branch? 09:45 < morimoto> Ah... yes 09:46 < morimoto> sorry, it is still v0.x version 09:46 < morimoto> After v1.0, I will not 09:46 < pinchartl> if I may chime in on this topic (being the main source of controversy...) 09:46 < pinchartl> I think we still haven't agreed on the development process 09:46 < pinchartl> and I don't see how we can build a tool to support a process if we don't define the process first 09:47 < pinchartl> that's been my issue since the beginning 09:47 < pinchartl> the face to face discussion Morimoto-san and I had in Tokyo answered lots of my questions 09:47 < pinchartl> and I tried to summarize the process discussions on the periperi mailing list 09:47 < pinchartl> but the mail thread quickly died 09:47 < pinchartl> to word this differently, I think we need to agree about what we want to do before doing it 09:48 < morimoto> 1 question. what is your problem ?? 09:49 < wsa> what are the open questions there? I am fine with trying morimoto-san's tools for now... 09:49 < damm> i think we should split the process discussion from the tool 09:49 < damm> that said, i agree that process is important 09:49 < pinchartl> morimoto: my issue is that we still don't know what we want to do 09:49 < pinchartl> there have been lots of bikeshedding discussions about the tool 09:50 < pinchartl> about the format of stored data 09:50 < morimoto> OK, yes, let's split the topic 09:50 < pinchartl> and other topics 09:50 < pinchartl> and to answer those questions, we first need to know what we want to do 09:50 < pinchartl> at the moment, I see a tool, and I have no idea how to use it 09:50 < damm> i don't disagree 09:50 < pinchartl> for instance 09:50 < pinchartl> for your last report 09:50 < pinchartl> you tried to use the tool to generate the e-mail 09:51 < pinchartl> there were no B) and C) 09:51 < pinchartl> which isn't surprising 09:51 < wsa> we are at the tool level again 09:51 < pinchartl> as the tool doesn't support tracking future work plans at a bi-weekly level 09:51 < pinchartl> nor does it support tracking blockers 09:51 < wsa> I agree that "reporting emails" should be maybe a second or third step for the tool 09:51 < pinchartl> so, as an experiment, you tried adding that information to the task description 09:51 < pinchartl> it then ended up in the generated report 09:52 < pinchartl> but that's a hack 09:52 < damm> but does it blend? 09:52 < pinchartl> and if we start using a tool without knowing what we want to do it with 09:52 < pinchartl> we'll keep making hacks like that 09:52 < pinchartl> in different ways, for different people 09:52 < pinchartl> it will quickly become unusable 09:52 < wsa> we first need to deal with handling tasks, or? 09:52 < pinchartl> personally speaking, the logical order would be 09:53 < pinchartl> 1. what are the issues we have? 09:53 < pinchartl> 2. how do we want to solve them? 09:53 < pinchartl> 3. how do we implement tools to support that? 09:53 < wsa> and I would still like to understand why we can't use the tool for that right now... 09:53 < pinchartl> if we start by 3, then 2, then 1, I don't see how it could work :-) 09:53 < morimoto> wsa: +1 09:54 < morimoto> Many times I explain it ... 09:54 < wsa> and I think it is not only about the issues we have but also about the issue Morimoto-san is having 09:54 < wsa> issues 09:54 < pinchartl> wsa: we have a mostly free-formed text format as a database. that won't work, we will end up with one format per person depending on personal preferences 09:54 < damm> pinchartl: i thought that it was the germans that liked process and order? 09:54 < pinchartl> see the discussion of 1 task per file vs. several tasks per file 09:55 < pinchartl> or Morimoto-san's today's e-mail report with free-formed B) and C) in the task description 09:55 < pinchartl> we haven't really started using this, and it's already forking :-) 09:56 < damm> my opinion is that people should use the tools that they like 09:56 < wsa> I do like processes, but there is just talk :) 09:56 < pinchartl> at the moment I feel that we're being given a database engine and we're told it's our bug and task tracker 09:56 < damm> but some interface/format is needed together with a known process 09:57 < pinchartl> what I'd like to get is jira/bugzilla/whatever. not those tools in particular, but something that operates at a similar level. with a defined work flow 09:57 < damm> how about the people that like processes come up with a process proposal? 09:58 < damm> i am for sure in the process camp 09:58 < damm> the we have a tool camp as well 09:58 < pinchartl> damm: let me locate the e-mail thread 09:58 < damm> once both are in semi-ok order we merge 09:58 < morimoto> I explained many times, but, I can create "Tool", but, you can create "Rule" 09:58 < damm> how many people are in the pro-process discussion camp? 09:59 < kbingham> I'm in the ... I want something that works camp ... 09:59 < damm> obviously not morimoto-san 09:59 < wsa> okay, let me summarize my take: 09:59 < pinchartl> morimoto: but my point is that the tool should be based on the rules, not the other way around 09:59 < damm> obviously laurent likes process 09:59 < kbingham> And ... I'm confused why we're writting our own tools when opensource tools already exist :) 09:59 < morimoto> pinchartl: yes, and, no my opinion 10:00 < morimoto> My opinion is like this 10:00 < damm> kibingham: i guess we need to know which problem we are solving first 10:00 < wsa> even the current process works for me as groupleader. not perfect, but works. I see Morimoto-san has problems reporting our progress upwards. I'd surely like to have this issue solved, it is important for all of us. 10:01 < morimoto> You can use Emacs, or VIM. it is editor. but, what you can write is under your rule. 10:01 < pinchartl> "Re: [periperi] Peri Tool Next" from "Date: Sat, 14 Jul 2018 05:27:30 +0300" 10:01 < pinchartl> Message-ID: <2412691.0qdXsgRgLR@avalon> 10:01 < wsa> I don't think I need details on this, because I'd think there is a lot of internal information and culture involved. 10:01 < damm> so why can't we simply do a work split? 10:01 < damm> break out the process discussion into a group that cares? 10:02 < damm> and figure out what we _need_ to do 10:02 < pinchartl> damm: that would work for me 10:02 < damm> then we can apply that to tools or whatnot 10:02 < damm> so currently the process group includes pinchartl and myself 10:03 < morimoto> my opinion is, try 1st, fix 2nd, rule 3rd :) 10:03 < damm> morimoto: that's why you are not in the process group =) 10:03 < morimoto> ok :) 10:03 < damm> morimoto: you are however very welcome to join if you'd like 10:03 < morimoto> I still don't understand what is the issue... 10:04 < damm> morimoto: you and i have discussed this before 10:04 < pinchartl> morimoto: ok, to make it very simple, my first issue is that with today's version of the tool, file format and documentation, I have no idea how to use it 10:04 < damm> if you get interested in the process let me know 10:05 < damm> pinchartl: you and i are at the same wave length 10:05 < morimoto> pinchartl: yeah, I don't know too. thus, it is "trial" 10:05 < pinchartl> damm: I don't know if that's a good or bad thing :) 10:05 < damm> but lets give morimoto-san freedom to poke around 10:05 < pinchartl> morimoto: shouldn't the trial phase be done separately from the production phase ? :-) 10:06 < damm> you are using process-think now =) 10:06 < damm> lets take that elsewhere 10:06 < morimoto> My opinion is, 10:06 < wsa> damm: I assume you know what is needed from the Renesas side for that process? 10:07 < damm> sort of 10:07 < morimoto> we can use tool to get all information. But we don't know how many information we have or we need, so far 10:07 < morimoto> So far I know is 10:07 < morimoto> 1) task, 2) BSP list 10:08 < morimoto> For each purpose, we can use 1) task/mm for example, 2) task/bsp, etc 10:08 < morimoto> each folder has each rule 10:08 < morimoto> few rule is it should use "clear Title", etc 10:09 < morimoto> we can create each rule for each purpose / each folder 10:09 < morimoto> Because of this, "tool" have limited rule 10:10 < morimoto> If you want to have "fixed" fule/format, you can create it 10:10 < morimoto> and force it by git hook ? 10:10 < morimoto> it is operation rule, not tool rule 10:10 < morimoto> this is my basic idea 10:11 < pinchartl> morimoto: I think the tool should enforce operation rules. otherwise they won't be enforced, and the "database" will be "corrupted" all the time 10:11 < damm> morimoto: this discussion is similar to someone wanting to cook a pancake and asks how to do it, but the answer is a swiss army knife. =) 10:12 < morimoto> pinchartl: tool has operation rules. like "status:" tag 10:12 < wsa> how urgent is all this? 10:12 < morimoto> ? sorry, what does your "operation rule" ? 10:12 < wsa> I am under the impression Morimoto-san may need the tool to create proper reports so we can be evaluated correctly 10:12 < wsa> but i may be wrong 10:13 < damm> wsa: i have my own tools to monitor upstream contribution rate for each group 10:13 < pinchartl> wsa: I think you're right, but it's not just the tool that's needed for that, it's also the data. reports can't be created before we all start using the tool and keep the data up to date 10:13 < morimoto> wsa: creating reports is option, not purpose 10:13 < wsa> ok 10:13 < wsa> that relieves me 10:13 < damm> and to avoid spending time unwisely i don't bother you with that unless things are not progressing as expected 10:14 < wsa> I have absolutely zero doubts in trusting Magnus and Laurent figuring out an awesome process... 10:14 < damm> it would be interesting to hear how shimoda-san and morimoto-san would like to receive information how to handle those BSP upporting lists 10:15 < wsa> ... yet they are both probably the busiest people we have? 10:15 < damm> are we in a rush somehow? 10:16 < wsa> that was my initial question. i thought so and I am happy I was wrong :) 10:16 < pinchartl> wsa: I think we're all busy. I agree however that I might be one of the people who sometimes has the hardest time setting priorities straight :) 10:16 < damm> pinchartl: it is good to see that someone cares 10:16 < damm> pinchartl: shall we take that process discussion elsewhere? 10:17 < pinchartl> and as we're all busy, if this new tools requires spending more time to keep data up to date, I'm pretty sure it won't happen. I don't see how it could be adopted unless it makes everybody's life easier 10:17 < pinchartl> damm: sure. on the mailing list ? or do you have another preference ? 10:18 < damm> pinchartl: lets use private email to schedule a video conference you and me 10:19 < pinchartl> is anyone else interested ? 10:20 < geertu> I'm interested in the outcome 10:20 < kbingham> perhaps in the outcome of discussions :) - and the list of features required 10:21 < pinchartl> alright 10:21 < pinchartl> damm: seems like we have a date then :-) 10:21 < damm> pinchartl: yay 10:22 < pinchartl> ok, let's do that 10:23 < wsa> damm: you have a second now to chat (IRC or Hangout)? 10:25 < pinchartl> damm: mail sent 10:26 * kbingham posts "PeriZilla" to "PeriPeri" and awaits to be laughed at 10:27 < pinchartl> damm: seems like our e-mails have crossed each other :) 10:29 < geertu> kbingham: is there a perl-bugzilla, too? 10:29 < kbingham> geertu, If not you could write one :D 10:29 * geertu notices the similarities between peri and perl 10:30 < uli_> geertu: bugzilla itself is written in perl; i'd be surprised if there weren't 10:30 < geertu> Are we finished with core? 10:30 < kbingham> geertu, https://devzing.com/blog/index.php/access-bugzilla-from-perl/ 10:30 < geertu> Any other topics to discuss? 10:34 < wsa> damm: you have a second now to chat (IRC or Hangout)? 10:34 < damm> wsa: hangouts pls 10:34 < pinchartl> geertu: not for me. I'm fine proceeding with multimedia 10:34 < geertu> OK. 10:36 < geertu> Thanks for joining, and have a nice continued day.