<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: ChanServ sets mode: +v hverkuil
pinchartl: why so ?
hverkuil: <u>mchehab</u>: I would have no problems with rebasing if needed. I agree with pinchartl, patches pile up too much. Subsystem-wide changes are not really suitable for that, it's better to wait until rc1, but it shouldn't matter for most PRs. And if there are merge conflicts, then we can ask the author to rebase and repost.
mchehab: <u>pinchartl</u>: changes at the media tree may happen from other upstream trees, like non-media kAPI changes
pinchartl: <u>mchehab</u>: can't that be handled with a merge ?
mchehab: on trivial cases, yes, but not sure what it would mean for git bisect.
<br> if we go this way, it probably makes sense to add a Jenkins job that will try to merge from upstream, compile and report any errors
<br> if such job fails, probably rebases (or merge conflicts) will be needed when those got merged back at the main tree
<br> anyway, we could make an experiment and see how it works, if ok for everybody - but no promises with regards to rebasing
<br> another alternative would be to have a sort of media-next that would be automatically handled via Jenkins
<br> that perhaps would work better
<br> having a script that would pick from media_tree master branch, merge it with fixes and with a "-next" branch from each maintainer
pinchartl: you may want to look what DRM does, they have a tree that is never closed
mchehab: if the merge fails from any tree/branch, it will just ignore the tree (sending an email)
pinchartl: and it's also never rebased
mchehab: DRM tree sucks. It is almost impossible to do git bisect there
<br> I tried a few times... it takes *hours* to discover a culpit patch
pinchartl: I've bisected it several times, I don't recall particular problems
mchehab: once, it took me several days to discover a bad patch at the amd GPU code that broke my display
<br> there are too many merge conflicts in the middle of the tree, handling all sorts of things, including kAPI changes internally at the DRM core code
pinchartl: how did yu manage to spend days on a git bisect ?
mchehab: the patch were touching a code that had several kAPI changes...
<br> also the amd code itself had several other changes
<br> making it really hard to find the issue, and just reverting the patch won't work
<br> I ended running with a legacy kernel for several months
<br> (the code in question were for a GPU that had both Intel and AMD code on it)
pinchartl: a GPU that is both Intel and AMD ??
mchehab: yes. there were a few devices that were shipped with both Intel and AMD gpus working altogether
<br> Radeon RX Vega M and Intel UHD Graphics 630
pinchartl: how would you explain that 100+ DRM/KMS co-maintainers have no issues with git bisect ? :-)
mchehab: <u>pinchartl</u>: I've no idea how they manage to do git bisect, but not interested on learn funny new ways to bisect just for an specific subsystem
-: pinchartl wonders why he bothers
mchehab: it is good to see that the DRM subsystem somehow is managing to do their jobs, but it is a way too different than what other subsystems are doing
<br> anyway, as I said, I'm ok to do some experiments, but IMHO, a model close to linux-next would be easier to implement
<br> if ok for all media maintainers, I can setup a media-next tree pulling from your media branches. I'll need the name of the tree(s)/branch(es) to pick from each maintainer...
<br> As this will be an automated job, the names of such trees/branches should either be something like "<maintainer>/media_tree next" or we may need to store them on a shared git repository, in order to avoid manual work as developers change their branches/trees
<br> I went ahead with the idea of having a media-next branch: https://builder.linuxtv.org/job/media-next/
<br> this should be creating daily media_next-2021* tags pulling contents from the master branch, from the fixes branch and to any other branches/trees we want
<br> (I'm right now testing the build script)
<br> the tree itself is at: https://git.linuxtv.org/media_next.git/
hverkuil: How does this help me? If I post a PR with patches for the next release, what happens with that PR?
<br> (trying to understand the workflow)
mchehab: <u>hverkuil</u>: this won't handle PRs
<br> but if you create a branch where you merge everything, I can add a fetch command for such branch
<br> this way, even before you issue a PR, you'll have a feedback if something bad happens
<br> this is helpful specially during the period where the merge is frozen
<br> so, for instance, if you create a "next" branch at https://git.linuxtv.org/hverkuil/media_tree.git/, I can set the script to pull from it
<br> you can use it to merge all the trees you're working with (like your "ctrl-refactor", "for-v5.13-out2", ...)
<br> this will be checked against the master tree, and against the -next branches from the other media maintainers
hverkuil: But I don't care about that. I'm not going to look at conflicts until rc1 is released. It's much easier to wait until rc1 is out and check any pending PRs only once at that time. It's pretty rare that there is a conflict, and I'd rather look at it only once then whenever it fails during this freeze period. What I want is to have pending PRs being accepted so that they are out of my flow and not piling up.
mchehab: if a conflict rises, people will be notified
<br> I can create a staging (or next) tree myself, where I can pull the pending PRs during the frozen period as we do during the merge window, adding it to the linux-next tree
<br> sorry, to the media-next tree
<br> hmm...
<br> perhaps instead I could make the script to also automatically add all pending PRs to media-next
<br> if they build fine
<br> in other words, two workflows will be allowed:
hverkuil: That would be nice. And then it is much more useful to know about conflicts. Although we need a procedure about what to do about conflicts.
mchehab: - 1) send me a list of tres/branches that media developers want the media-next to pick;
<br> - 2) all PRs will be automatically handled
<br> not sure if we can define a procedure about what to do with conflicts... I mean, this will need to be handled case by case
hverkuil: This still leaves the PR unreviewed by you, i.e. it still remains in my patchwork TODO list.
mchehab: one thing: the Jenkins job will be doing a full {allmod|allyes}config. If anything fails, it will drop the tree from the daily build.
<br> <u>hverkuil</u>: at the moment, yes. What I can do is to create a "linux-staging" tree where I merge the PRs, and that can be rebased
<br> and let the script pull from it
<br> but I'm not sure I'll have enough time to do it on this merge window
hverkuil: That would be ideal. And if there are conflicts with a PR, then it would make sense to back out the relevant patches and request the submitter to resubmit. It would be fine for me if such a linux-staging tree would be rebased when dropping patches.
mchehab: yeah, having a media-staging will help us to avoid the need to rebase the media_tree
<br> (we don't rebase it often, but sometimes we had to)
<br> we can use the staging tree as the basis for linux-next, and place things at the main tree only after being tested there
<br> anyway, the workflow changes for me would be significant. I need some time to prepare for a change like that
<br> I'll try to do it during the next merge window
<br> so, recap everything, we'll then have:
<br> media-next - auto-generated by Jenkins with stuff merged from PRs, from fixes and from sub-maintainers "-next" branches;
<br> media-staging - where I'll be applying PRs - this will also be reflected at the next day's media-next
<br> linux-next will start picking from media-staging
<br> media_tree will be updated the day after linux-next tests pass
<br> I ended dropping an e-mail. better to discuss it at the media maintainers ML