wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 390 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180823-core-chatlog b/wiki/Chat_log/20180823-core-chatlog
new file mode 100644
index 0000000..4be234b
--- /dev/null
+++ b/wiki/Chat_log/20180823-core-chatlog
@@ -0,0 +1,390 @@
+Core-chat-meeting-2018-08-23
+
+09:35 < geertu> Welcome to today's Core Group Meeting!
+09:35 < geertu> Agenda:
+09:35 < geertu> 1. Status Updates
+09:35 < geertu> 2. Discussion Topics
+09:35 < geertu> Topic 1. Status updates
+09:35 < geertu> A) What have we done since last time:
+09:35 < geertu> Kaneko-san upported M3-N CPUFreq upport.
+09:35 < geertu> Marek worked on U-Boot (discussing PCI DT parsing, and Gen2 USB PHY) and
+09:35 < geertu> Linux (PCIe link L0/L1 switching on Gen3).
+09:35 < geertu> Morimoto-san worked on PeriJect and Ebisu-4D export (Laurent/Simon/Geert).
+09:35 < geertu> Shimoda-san says the RVC test team will test the new LTSI v4.14 snapshot.
+09:35 < geertu> Simon tested M3-N CPUFreq, and submitted backports for LTSI-4.14.
+09:35 < geertu> Ulrich sent H3/M3-W cpuidle support.
+09:35 < geertu> Geert tested Simon's 4.14.61-based backport.
+09:36 < geertu> B) What we plan to do till next time:
+09:36 < geertu> Marek will continue Linux PCIe L0/L1 switching and U-Boot PCI DT parsing
+09:36 < geertu> discussions.
+09:36 < geertu> Morimoto-san will continue PeriJect development and Ebisu-4D export
+09:36 < geertu> (Magnus).
+09:36 < geertu> Shimoda-san will check the new LTSI v4.14 snapshot test results from the
+09:36 < geertu> RVC test team, and will pave the way forward for IPMMU.
+09:36 < geertu> Simon will continue testing M3-N CPUFreq.
+09:36 < geertu> Geert will continue QEMU GPIO virtualization, handle SYSC and PFC errata,
+09:36 < geertu> and review LTSI submissions during the merge window.
+09:38 < geertu> C) Problems we have currently:
+09:38 < geertu> Marek needs feedback from HW team on the PCI L0/L1 switching.
+09:38 < geertu> Anything I missed?
+09:38 < Marex> shimoda: OK, email sent, please let me know if I can tweak it somehow to get useful feedback from the HW team soon :)
+09:39 < geertu> Topic 2. Discussion Topics
+09:39 < geertu> Anything to discuss?
+09:40 < damm> memory auto detect!
+09:40 < damm> how to proceed
+09:40 < pinchartl> I'd like to discuss handling of BSP patches, in relation with periject
+09:40 < pinchartl> damm: you can go first
+09:41 < geertu> uli___: Any update?
+09:41 < damm> thankssssssssssssssssssss
+09:41 < uli___> not from me
+09:41 < shimoda> Marex: Thank you for the email! by the way, what's your envirnoment? H3 ES1.x?
+09:41 < damm> so whats the next step forward with the memory detection i wonder?
+09:42 < Marex> shimoda: H3 ES2
+09:43 < shimoda> Marex: Thanks!
+09:43 < geertu> Marex: You had some feedback from the generic U-Boot side?
+09:43 < Marex> shimoda: the latest greatest is H3 ES3, right ? :)
+09:43 < Marex> shimoda: you're welcome
+09:43 < damm> i suppose this topic is related to ATF
+09:43 < Marex> geertu: generic u-boot side of ... what ?
+09:43 < geertu> memory detection
+09:43 < Marex> geertu: oh that
+09:43 < Marex> geertu: nope, nothing
+09:44 < Marex> geertu: I can just implement the decoder for the ATF memory layout tables and put it in ...
+09:44 < damm> we have no ATF code in upstream yet, right?
+09:44 < shimoda> Marex: you're right :)
+09:44 < damm> but i recall Marex doing some work somewhere
+09:44 < Marex> damm: not yet, sorry
+09:44 < Marex> damm: I upported the D3/V3M ATF to 1.0.22r2 (latest)
+09:45 < Marex> damm: I didnt start feeding it upstream yet
+09:45 < damm> to have at least one known working system with autodetection, perhaps we can upstream ATF support for one board/SoC and complete upstreaming of the u-boot portion too?
+09:45 < Marex> damm: the U-Boot portion is easy I think
+09:46 < Marex> damm: from what pinchartl told me, the ATF just puts memory layout tables in RAM, so U-Boot can parse that and fill linux DT with that information
+09:46 < damm> i suppose we want something robust so in case ATF doesn't support memory detection we still have working upstream u-boot
+09:47 < Marex> damm: fall back to small amount of memory that's always present ?
+09:47 < damm> sure
+09:47 < damm> i suppose we want to disconnect the upstreaming/upgrade path of u-boot from ATF
+09:47 < geertu> Seems like there's also an H3ULCB with 8 GiB of RAM?
+09:48 < Marex> damm: yes, those things should be separate
+09:48 < damm> but starting with ATF must make sense so we don't implement code in u-boot that can't be merged
+09:48 < Marex> damm: there should be a minimum version requirement for ATF on which U-Boot and Linux works fine, but that's about it
+09:49 < Marex> damm: start with ATF how ? by patching it support passing some more sane memory info to the upper layers ?
+09:50 < damm> i guess since everything is out of tree when it comes to ATF we don't want to make it more difficult than necessary to adopt upstream code
+09:50 < damm> i would say upstreaming of ATF for one platform
+09:50 < Marex> damm: sure
+09:51 < damm> some basic minimal support level
+09:51 < damm> and then add that auto-detection bit
+09:51 < damm> that would make sense to me at least
+09:51 < Marex> damm: the autodetection can be implemented with current ATF already, the question is whether that (those tables that ATF populates) can be considered an ABI
+09:52 < damm> then we can handle features and other SoCs/board incrementally after that
+09:52 < damm> out of tree ABIs are not exactly smelling good in my book
+09:52 < Marex> damm: right
+09:53 < damm> so shall we get Renesas to approve upstreaming of H3 ATF for instance?
+09:53 < damm> would anyone including Marex and Uli be interested in that kind of work?
+09:54 < geertu> damm: Yes please (for upstreaming)
+09:54 < Marex> damm: I have upstreaming of the ATF for D3/V3M on my list I wrote in Japan
+09:55 < damm> ok so lets check with Renesas about preferred platform out of D3/V3M/H3
+09:55 < damm> I suppose we can make use of memory autodetect on H3 mainly
+09:55 < Marex> :-)
+09:55 < damm> but hey, this is just an ordering problem really
+09:56 < geertu> For H3/M3-W/M3-N, the memory is on the SiP (for M3-N that may not be true for production SoCs)
+09:56 < geertu> Is there any ID on the SiP that can be read?
+09:57 < damm> that would indeed be nice
+09:57 < geertu> Which brings us to [PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP"[PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP" (https://www.spinics.net/lists/devicetree/msg173820.html) again ;-)
+09:58 < geertu> No, we don't want _more_ DTS files to maintain...
+09:58 < Marex> geertu: but if it's SiP, someone can populate pretty much random DRAM chip on it, right ?
+09:58 < Marex> geertu: it's just a matter of soldering it on
+09:59 < geertu> Marex: the same is true for boards with an SoC instead of an SiP
+09:59 < geertu> Although soldering the SiP may be a tiny bit harder ;-)
+10:00 < geertu> Anyway, we're deviating.
+10:00 < geertu> So:
+10:00 < geertu> 1) upstream ATF for one R-Car Gen3 SoCs
+10:00 < geertu> 2) update ATF for memory auto-detected
+10:00 < geertu> 3) update U-Boot for memory auto-detect
+10:00 < geertu> Sounds good?
+10:00 < damm> yeah perfect
+10:00 < damm> thanks
+10:01 < Marex> geertu: sounds good
+10:01 < damm> oh one thing
+10:01 < Marex> geertu: so we just need the approval for H3/M3x or get me a physical D3/V3M :-)
+10:01 < damm> will uli simply hand over stuff to Marex then?
+10:02 < uli___> i would prefer that
+10:02 < damm> lets do that then
+10:02 < shimoda> damm: about ATF upstreaming, does it need Renesas side help? or, we can upport from in-house code anyway?
+10:02 < damm> shimoda: maybe q&a is needed
+10:03 < damm> shimoda: but apart from that i don't expect much help is needed
+10:03 < Marex> shimoda: I think the goal would be to move in-house code (after cleanup and maybe rewrite) to upstream ... and then there would be no more inhouse code :)
+10:03 < damm> Marex: what do you think?
+10:05 < shimoda> damm: i see... I heard BayLibre tried upstreaming ATF but they have many questions to Ito-san, but since Ito-san and renesas ATF team are very busy, so no progress now... ;)
+10:05 < Marex> damm: I might have a few questions if there are registers which are not in the documentation or weird things happening, but in general from what I saw, not much help would be needed
+10:05 < damm> so letting Marex use the in-house code as sample and then he can decide by himself how to handle upstreaming?
+10:05 < damm> shimoda: maybe our friends at BL will be happy with some assistance then
+10:05 < geertu> Any political conflict with BayLibre?
+10:06 < damm> don't think so
+10:06 < damm> so lets see how Marex will accelerate this activity =)
+10:06 < geertu> Great!
+10:07 < shimoda> damm: should I ask Ito-san about who is trying to upstream in BayLibre?
+10:07 < geertu> Last(?) topic: BSP and periject?
+10:07 < damm> shimoda: sure, and please ask about what target platform they focus on
+10:07 < Marex> damm: can I get a go/no-go when you check with BayLibre and input on which SoC I should use for upstreaming (H3/M3x/D3/V3x) ?
+10:08 < damm> sure
+10:08  * pinchartl takees the microphone
+10:08 < damm> will let you know
+10:08 < Marex> damm: thanks, so in the meantime I'll keep haggling about the PCI
+10:08  * geertu releases
+10:08 < shimoda> damm: i got it
+10:08 < pinchartl> I attended the "periperi process meeting yesterday"
+10:08 < Marex> on both U-Boot and Linux front no less , sigh
+10:08 < Marex> damm: thanks
+10:08 < pinchartl> which turned out to be a discussion between Magnus and I :-)
+10:09 < pinchartl> we spent two hours going around many topics
+10:09 < morimoto> wow
+10:09 < jmondi> I missed it was yesterday, my bad
+10:09 < pinchartl> no worries
+10:10 < pinchartl> we decided to segment the problem, as handling everything in one go would be a too large task
+10:10 < pinchartl> so the topic I'd like to discuss today is handling of the BSP patches
+10:10 < pinchartl> today's situation is as follows (in a very summarized form)
+10:10 < morimoto> This is good timing, we got new upport list from BSP team
+10:11 < pinchartl> we, the upstreaming team, work on the upstream kernel
+10:11 < pinchartl> Renesas consumes the result of our work, through renesas-drivers, and creates BSPs
+10:11 < pinchartl> there are several layers there, as not all kernel code is in the public BSP (I'm thinking about codec drivers for instance)
+10:11 < pinchartl> and I'm sure there are customer trees as well
+10:12 < pinchartl> but in a nutshell, we get a BSP
+10:12 < damm> (or a bucket of mud as i referred to it)
+10:12 < pinchartl> the BSP is the result of a process that takes the upstream kernel, identifies issues (bugs, performance problems, missing features...), and fixes those issues
+10:13 < pinchartl> that process, internally, uses various means of bug tracking (including lots of excell spreadsheets from what I've been told), to which we have no access externally
+10:13 < wsa> all Japanese, too, probably?
+10:13 < neg> damm: :-)
+10:14 < pinchartl> as an upstreaming team, we strive for feature completeness, stability and performances
+10:14 < pinchartl> so it is of value to us to know about the issues that have been identified
+10:14 < pinchartl> we have started efforts to implement automated tests ourselves to catch regressions and other problems
+10:15 < pinchartl> but given that we are resource-constrained, we can't match for now all the testing effort done internally by Renesas
+10:15 < pinchartl> and by Renesas' customers (I've been told that customers are the best source of bug reports)
+10:15 < pinchartl> wsa: and yes, lots of information is in Japanese
+10:15 < pinchartl> so that's the current situation
+10:15 < pinchartl> now, where do we want to go ?
+10:15 < pinchartl> *ideally*
+10:16 < pinchartl> we should get access to a common issue tracker, with all the information available for all identified issues
+10:16 < pinchartl> that's something I'd like to happen, but it's a very long term project
+10:16 < pinchartl> we can't expect that in the short or mid term
+10:17 < pinchartl> so today, our largest source of information about issues in the upstream kernel is the BSP
+10:17 < pinchartl> as most BSP commits fix an issue (alleged or real)
+10:18 < pinchartl> for that reason, Magnus and I agreed that we need to base our process to achieve feature completeness, stability and performances partly at least on the BSP commits
+10:19 < pinchartl> furthermore, we are, at least partly, evaluated on how we reduce the delta between the BSP and upstream
+10:19 < pinchartl> and thus on the amount of BSP code that we "upport"
+10:19 < pinchartl> "upporting" here means either direct upporting, or development of equivalent fixes
+10:19 < pinchartl> so it's often more about superseding the BSP commits than really uppporting them
+10:20 < pinchartl> it's thus useful internally for Renesas, at least if my understanding is correct, to track how BSP commits are replaced
+10:20 < pinchartl> we thus need a list of BSP commit, associated with a status, in order to track our progress
+10:21 < pinchartl> both on our side, to make sure no BSP commit falls through the cracks, and on Renesas' side, to evaluate progress
+10:21 < pinchartl> we have such a list, in a shared git tree
+10:21 < pinchartl> but there's one issue that I haven't mentioned yet
+10:21 < pinchartl> BSP commits come with very little information
+10:21 < pinchartl> there's often no commit message
+10:21 < pinchartl> and when there's a message, it's usually terse
+10:22 < pinchartl> there's usually no information about which platforms are affected by the issue
+10:22 < pinchartl> or how to reproduce it
+10:22 < wsa> ^ that!
+10:22 < pinchartl> or the userspace use cases
+10:22 < pinchartl> we are thus often left in the dark
+10:23 < pinchartl> and we randomly send e-mails to Morimoto-san, sometimes CC'ing the author of the BSP commit, asking for clarifications
+10:23 < pinchartl> that's not a very efficient process
+10:23 < pinchartl> as information gets lost somewhere in mailing list archives
+10:23 < pinchartl> or in private e-mails
+10:24 < pinchartl> so Magnus and I are proposing storing additional information in the database of BSP commits
+10:24 < pinchartl> which would become, in a way, an interface with the BSP team
+10:24 < pinchartl> when a new BSP is released, the BSP team will add commits to the database (they already do today)
+10:25 < pinchartl> and our proposal is to add a way for the BSP team to add a description for each commit
+10:25 < pinchartl> ideally that wouldn't be needed
+10:25 < pinchartl> as all information we need should be in the commit messages
+10:26 < pinchartl> but realistically that won't happen
+10:26 < pinchartl> we should try to get there gradually, but things will never be perfect anyway
+10:26 < pinchartl> so, the idea is to have, for each BSP commit, a status, and a description
+10:26 < pinchartl> if we need more information we can just mark the commit as requiring information
+10:27 < pinchartl> all that would still be stored in a git tree, as it is today
+10:27 < pinchartl> and both us and the BSP team would have access to that tree
+10:27 < pinchartl> we need to extend the storage format used today for the BSP commits
+10:28 < pinchartl> and, on top of that, tools could also be developed
+10:28 < pinchartl> as long as the storage format is defined, we could even have multiple tools, command-line-based, GUI, web-based, if someone has time to spend :-)
+10:29 < geertu> Sounds good to me. thx!
+10:29 < pinchartl> to conclude on the topic, what we'd like to agree on, is the data storage format, and the process to handle BSP commits
+10:29 < kbingham> Another git-backed-information-storage tool I came across lately might be of interest on this topic:  https://github.com/sit-fyi/sit
+10:29 < pinchartl> (who adds them, who updates them, how, ...)
+10:29 < pinchartl> now the mic is yours, we take questions :-)
+10:30 < pinchartl> kbingham: thanks for the link
+10:30 < damm> may i raise two points from my side?
+10:31 < pinchartl> sure
+10:31 < damm> thanks for sharing the details very well
+10:31 < damm> i just wanted to mention two things
+10:31 < damm> 1. we should remember that BSP is one source of issues
+10:32 < damm> issues may come from a mailing list too for instance
+10:32 < damm> 2. we will have multiple buckets in progress at any given time
+10:32 < kbingham> Or issues /we/ find in our testing :)
+10:32 < pinchartl> damm: regarding the first item
+10:32 < pinchartl> sure
+10:33 < pinchartl> we also get requests or bug reports by e-mail
+10:33 < wsa> we also find bugs by ourselves :)
+10:33 < pinchartl> (both e-mails from Renesas and from third-parties, in public or private e-mails)
+10:33 < pinchartl> possibly on IRC
+10:33 < damm> yeah, so no need to keep a too bsp-upport centric view
+10:33 < pinchartl> and there are bugs we find ourselves, yes :-)
+10:33 < pinchartl> so yesterday we also discussed the need to have an issue tracker
+10:34 < pinchartl> which would be at a level just above the BSP commit tracker
+10:34 < pinchartl> but that's a second step, I don't want to try and solve all problems in one go as I explained in the beginning
+10:34 < damm> totall agree, thanks!
+10:34 < pinchartl> tracking BSP commits is the low-hanging fruit in my opinion
+10:34 < pinchartl> as we know it's useful and needed
+10:34 < pinchartl> (both for us and Renesas)
+10:35 < pinchartl> the information we need to track are limited, the workflow is simple
+10:35 < pinchartl> so it can be implemented in a relatively simple way
+10:35 < pinchartl> once we get there I'd like to move to issue tracking
+10:35 < pinchartl> of course if someone has too much free time, we can work in parallel :-)
+10:36 < jmondi> one question: instead of going in the "BSP -> issue tracker" direction, shouldn't it be smarter to setup an issue tracker and ask BSP to use it? so that it's there already for us to use if we have bugs to list too
+10:36 < geertu> Public bug reports (email, irc) are usually fixed quicker, mostly because there's a direct link with the reporter, leading to more accurate bug information.
+10:36 < jmondi> it would also force BSP to reason in terms of "issue -> patch series" not the other way around
+10:36 < pinchartl> jmondi: that's a very good question
+10:37 < pinchartl> and I think the answer is yes
+10:37 < pinchartl> but I'm concerned about how to get there
+10:37 < pinchartl> I'd like to tell the BSP team today that we'll stop taking BSP commit directly, and that they should file proper issue reports
+10:37 < pinchartl> but I doubt they will
+10:38 < pinchartl> my hope is that, but creating a BSP commit tracker that they feed as they do today
+10:38 < wsa> I'd think our possibilty to "force" something onto the BSP team is limited
+10:38 < jmondi> run a $BUGZILLA hosted by renesas?
+10:38 < jmondi> I'm sure it might take a long time, but...
+10:38 < wsa> I think we should aim for cooperation
+10:38 < pinchartl> with an additional feature of having a description they can fill as well
+10:38 < pinchartl> will let us push them to fill descriptions
+10:38 < pinchartl> once they get used to that
+10:38 < wsa> They probably have lots of other issues/people to deal with
+10:39 < jmondi> wsa: as well as we do
+10:39 < pinchartl> we could get better commit messages in the first place
+10:39 < pinchartl> and it might be easier to ask them to transition from BSP commit tracking to issue tracking too
+10:39 < pinchartl> maybe I'm too optimistic though
+10:39 < jmondi> wsa: I just don't think it's efficient we go through the process "Oh look a series, who knows what it tries to solve"
+10:39 < wsa> it isn't
+10:39 < pinchartl> but the only way I see to get better information is to make it more painful for them when they don't provide the information :-)
+10:40 < pinchartl> if a commit has no commit message, we just send it back, asking for information
+10:40 < wsa> I could imagine a workshop
+10:40 < jmondi> so if we spend a day trying to figure out what they meant to solve, they can spend 10 minutes creating issues, and linking there the series that tackle the issue
+10:40 < pinchartl> if we always do that consistently and stop trying to guess what the commits do, they might get the message
+10:40 < wsa> or any other way to give examples
+10:41 < jmondi> sorry, I don't mean to be rude, but I don't get why we have to treat them as uncapable of adhering to a process
+10:41 < pinchartl> our responsability will be to mark the BSP commits we supersede
+10:41 < jmondi> what's hard in "if you want to have a commit usptreamed, open an issue"
+10:41 < Marex> jmondi: the redmine running at osdr has a tracker plugin
+10:41 < pinchartl> the BSP team's responsability will be to provide us with detailed information about the issues
+10:42 < jmondi> pinchartl: yup
+10:42 < wsa> is there a language barrier?
+10:42 < pinchartl> jmondi: the hard part in "if you want to have a commit usptreamed, open an issue" is that *they* don't want to get commits upstreamed
+10:42 < pinchartl> we do
+10:42 < pinchartl> because we're asked to do so by Renesas
+10:42 < jmondi> s/we/Renesas
+10:42 < pinchartl> it's a case of left hand not talking to the right hand
+10:42 < wsa> I see Shimoda-san and Morimoto-san translating a lot
+10:43 < jmondi> fine, so that's an internal Renesas issues then :)
+10:43 < pinchartl> as I understand it, we're part of an external feedback loop that goes through multiple teams internally
+10:43 < jmondi> a team in Renesas wants BSP commits to be usptreamed, BSP doesn't care... that's an issue
+10:44 < pinchartl> (I don't know exactly how it works internally of course)
+10:44 < Marex> jmondi: big company, multiple departments with different management people and management strategies
+10:44 < jmondi> I understand it's not an easy issue
+10:44 < Marex> jmondi: some want FOO, others want BAR
+10:44 < jmondi> :)
+10:45 < damm> discussing with Renesas about how to improve the process must be a good thing
+10:47 < pinchartl> so, time for a conclusion
+10:47 < pinchartl> damm: will you do the honours ? :-)
+10:47 < horms> <2c> It seems to me that this is primarily a process rather than a tooling issue. And a cross-team process issue at that. So I agree some sort of cross-team discussion would likely be valuable </2c>
+10:48  * morimoto phew long English...
+10:48 < morimoto> 1st, we can ask BSP team soemthing
+10:48 < pinchartl> horms: agreed, it's a process discussion. we can then build tools on top of it, if desired
+10:48 < morimoto> And from next BSP release, we are already requesting about BSP commit log
+10:48 < morimoto> more clearly
+10:48 < morimoto> It seems they want to some kind of "format"
+10:48 < damm> i think i should have a q&a with the renesas folks using the chat log until next time if someone could include the chat log in the report
+10:49 < morimoto> Many BSP team member are working, but they are beginner
+10:49 < pinchartl> geertu: will you include this in the core meeting report ?
+10:50 < morimoto> if we can show format, they can followcl
+10:50 < morimoto> s/followcl/follow
+10:50 < morimoto> I think it can 1st step ?
+10:50 < geertu> pinchartl: Yes I will
+10:50 < morimoto> And about database, how about our Redmine ?
+10:51 < pinchartl> geertu: thanks
+10:51 < morimoto> I know some member want to use "git" base database, but Redmine is tracking tool
+10:51 < pinchartl> morimoto: redmine as an issue tracker is certainly an option we can consider
+10:51 < morimoto> No new tool is needed.
+10:52  * kbingham is only exploring git based tool options :) - no git requirement from me.
+10:52 < morimoto> Now we are usign "wiki" feature only
+10:52 < morimoto> it is "mottainai"
+10:52 < pinchartl> I wonder if it's a good option to track BSP commits though, as it would mean that the BSP team would have to open a redmine ticket for every BSP commit (or sets of commits). do you think they could do that ?
+10:52 < morimoto> I think we can't force them to focus it
+10:53 < pinchartl> morimoto: thank you for the Japanese lesson of the day. I agree about the mottainai
+10:53 < morimoto> They are busy guy
+10:53 < pinchartl> I expect them to be busy, yes
+10:53 < morimoto> pinchartl: Sorry, I don't know about English version of it
+10:53 < geertu> The advantage of anything git-based over redmine is that it works offline.
+10:53 < damm> and lacks a gui
+10:53 < morimoto> Thus, me or Shimoda-san pick-up, and do something is possible
+10:54 < pinchartl> (https://en.wikipedia.org/wiki/Mottainai)
+10:55 < damm> you could consider utf8 mottainai compared to shift-jis
+10:55 < shimoda> morimoto: Redmine can change the language by 個人設定
+10:56 < pinchartl> damm: https://upload.wikimedia.org/wikipedia/commons/b/ba/JIS_and_Shift-JIS_variants.svg
+10:56 < morimoto> shimoda: I mean "mottainai" English, not "Redmine" :)
+10:57  * geertu wonders what's the "R-Car Emotion Engine" (https://elinux.org/Emotion_Engine_SDK_Image_preparation_guide)
+10:57 < shimoda> shimoda: oops, sorry :)
+10:57 < jmondi> morimoto: you and shimoda-san are the ones taking the most burden from this, translating back and forth, asking question etc.. there's no way your team can agree on a process with BSP to mediate all upporting requests through redmine?
+10:58  * kbingham clicks geertu's link and wonders who RKDM is...
+10:58 < geertu> jmondi: Or rebase -i and add the info to the commits (excessive (sic) information under the "---" line?)
+10:58 < jmondi> again, I think "forcing" them to reason through "issue first -> then patches" would make things a lot smoother
+10:59 < pinchartl> geertu: we would lose commit IDs, I don't think that would be very usable in the end
+10:59 < damm> pinchartl: that table is geek t-shirt material for sure
+10:59 < pinchartl> if we could get back to the topic at hand :-)
+10:59 < jmondi> geertu: they want fixed format and I feel like an issue request on redmine would force them to use a standard tool and not think about "formats"
+10:59 < pinchartl> 1. do we want to replace the git BSP commit list with redmine ?
+11:00 < pinchartl> 2.1. if so, who will create the redmine issues ?
+11:00 < damm> i dont think so
+11:00 < pinchartl> 2.2. if not, do we agree with the process that I have proposed ?
+11:00 < pinchartl> I would personally answer no to the first question because I can't see a good answer for 2.1.
+11:00 < damm> worth discussing perhaps, but in a different setting?
+11:01 < morimoto> pinchartl: "git BSP commit list" = periupport ?
+11:01 < pinchartl> damm: would you like to take this internally and report the result of the discussions in the next meeting ? (or possibly before)
+11:02 < damm> sure
+11:02 < Marex> geertu: probably some AI thing ?
+11:02 < pinchartl> morimoto: yes, git BSP commit list = periupport, but with a different format to allow adding descriptions (including platforms, userspace context, use cases, ...)
+11:02 -!- horms_ [~horms@penelope-musen.amstelveen.horms.nl] has joined #periperi
+11:02 < geertu> pinchartl: Or store it in periject?
+11:02 < morimoto> Ahh, OK
+11:03 < wsa> i think the biggest difference between periupport and what you proposed is a clear "status"
+11:03 < wsa> like "need info"
+11:03 < morimoto> geertu: yeah agree. how about to use periject with such tag ?
+11:03 < pinchartl> geertu: I want to agree on the process and interface with the BSP team (a.k.a. data format). tooling is a separate discussion, on top of this
+11:03 < wsa> currently this is hidden in the free form text field and might be easy to miss
+11:03 < geertu> pinchartl: Do you want to script redmine queries?
+11:03 < pinchartl> wsa: yes, we need a status field, and at least a comment field
+11:04 < pinchartl> (and possibly other fields such as platform, although that could possibly be included in the comment/description)
+11:04 < wsa> so, a status field like, "worked on", "accepted", "rejected", "need info" etc would be a good addition IMO
+11:05 -!- horms [~horms@ip4dab7138.direct-adsl.nl] has quit [Ping timeout: 252 seconds]
+11:05 < pinchartl> depending on the result of the internal discussions, I'll try to propose a format
+11:06 < pinchartl> can that be our conclusion for today ?
+11:07 < damm> seems all good to me at least
+11:07 < neg> I think the discussion have been real good and I agree with pinchartl. However I'm a bit unclear how this new periupport repo will be handeled by us, do the whole team push directly to it?
+11:07 -!- horms_ [~horms@penelope-musen.amstelveen.horms.nl] has quit [Ping timeout: 265 seconds]
+11:08 < pinchartl> neg: that's part of the process that needs to be defined. I think we should all be allowed to push, yes
+11:08 -!- horms_ [~horms@penelope-musen.amstelveen.horms.nl] has joined #periperi
+11:08 < kbingham> What ever the resulting solution - we /need/ to have global access to add comments etc.
+11:08 < neg> I think maybe group leaders should be involved in changes somehow but sending patches on ML seems a bit of extra workload for them
+11:09 < geertu> neg: Agreed
+11:10 < jmondi> what about 'locking' the master branch and have group leaders cherry-picking from developers' branches?
+11:10  * morimoto I will talk this topic with BSP team
+11:10 < jmondi> I agree sending periupport patches is a bit of a waste, but I would like to make sure my udpates to the upport list are validated first.. I would have screwed up a few times already
+11:11 < pinchartl> jmondi: think about a regular issue tracker for a minute, like jira for instance. imagine how it would be if you couldn't modify anything yourself and always had to go through someone else :-)
+11:12 < jmondi> well, not always, updates to periupport happens weekly at the most to me
+11:12 < pinchartl> and they should happen more frequently
+11:13 < pinchartl> whenever you get a patch accepted upstream, the corresponding BSP commit(s) should be updated
+11:13 < neg> I think we reached the point where we need to empolye a secretarial pool :-)
+11:13 < jmondi> well, usually it takes me  ~week to upport a series
+11:13 < jmondi> neg: seconded
+11:13 < pinchartl> anyway, I propose closing this topic to start the multimedia meeting. we're only an hour and 15 minutes late :-)
+11:14 < jmondi> pinchartl: we're not -only- upporting, I hardly see me updating periupport daily
+11:14 < jmondi> ok, sorry
+11:14 < jmondi> I'll get back when the secretarial pool selection process topic is raised again
+11:15 < pinchartl> geertu: anything else for the core group ?
+11:15 < geertu> pinchartl: Don't think so.
+11:16 < geertu> Thanks for joining, and have a nice continued day (and/or meeting)!