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)!