We currently support 2 releases back and sometimes do multiple dot releases. At this time, krogoth is on 2.1.2 and will likely see a 2.1.3 as well. Patches that go onto the mailing list that are backports have the old release name in the subject aka [morty]. These backport patches should be tracked as well to 1) run patchtest on the old release with the patch 2) change the status when the patch goes into the testing branch of the old release. This is a bit harder as it may require we standardize on a naming scheme? 3) change status when it goes into the origin/release branch. 4) In a perfect world, it would be great to track if the patch went into a released tag vs was just on the krogoth branch so we could see that of the last 6 [krogoth] patches, 5 of them are in 2.1.2 and the sixth is in origin/krogoth but didn't make 2.1.2...
To be clear, we need to be able to handle patches against release branches automatically in the same way we do for patches against master. The first step is to attempt to detect the branch - patch emails will come in with either [branchname] or [for-<branchname>] in the subject (typically the former). We know the list of branches - these should be gathered from the repository and not hardcoded. If there's no match, assume master. Once we know which branch the patches are intended for, we can attempt to apply the patches on top of it. Apart from knowing which staging branch name to use (which is really part of bug 10715, not this one) the rest of the behaviour should be the same as for master.
(In reply to comment #1) > To be clear, we need to be able to handle patches against release branches > automatically in the same way we do for patches against master. > > The first step is to attempt to detect the branch - patch emails will come > in with either [branchname] or [for-<branchname>] in the subject (typically > the former). We know the list of branches - these should be gathered from > the repository and not hardcoded. If there's no match, assume master. > This is already implemented for a **single target branch**, but this bug 9946 feature is missing. if no target branch, defaults to master. > Once we know which branch the patches are intended for, we can attempt to > apply the patches on top of it. Apart from knowing which staging branch name > to use (which is really part of bug 10715, not this one) the rest of the > behaviour should be the same as for master. Right. For the moment all tests are release/branch agnostic.
This change implies probable use of alternative branches and new patch-statuses. This will be further discussed as it is a requirement for several enhancements. Moving this bug to 2.4 to allow this.
As mentioned above, additional branches can be monitored the same way as master for patchwork to automatically update to a specific patch status to reflect this. I've asked in bug 10715 to define which branches should be monitored and what status name should be created in patchwork, so please contribute here or in the mentioned bug to create that branch/status matrix. In regards to patchtest, as Leo mentioned, we are waiting for bug 9946, so I'm adding it as a dependency.
This request must include proper handling of patches with same name, but targeted to different releases (that are defined in each patch's subject), that should be displayed in the same series revision. Current behavior is that these patches are treated as successive revisions, wrongly superseding each patch by the newest one, for example: https://patchwork.openembedded.org/series/6455/#
I'm changing the target milestone to the same as the dependency (9946). As a side note, patches with same name but targeted to different releases probably should be treated as individual series. Then, patchwork can track each branch HEAD separately and update the patch status accordingly.
For clarity, this is what needs to be done: bug 9946 will handle the patchtest tests for other releases, and this bug will show work for tracking the "2 more recent" release branches at the source repositories, which will then update the patch status accordingly at patchwork. I'm renaming this bug to reflect this.
I've submitted a patch that creates an individual series for each patch or series of patches that contain a valid release name in their subject line [1]. This will allow to track separately patch series that contain the same base subject. Remaining item is to add the previous-release branches to what patchwork tracks (currently: master, master-next) and create a patch-status for each one of them. I suggest a release-master and release-master-next combination for the new status names, for example: "pyro-master", "morty-master-next". These changes to tracked-branches list will be queued for implementation in production, but will have to wait until after 2.4 milestone is done. [1] https://lists.yoctoproject.org/pipermail/yocto/2017-September/037776.html
I've added morty, pyro and rocko branches to patchwork's STATE_MAP in commit [1], and created the patch states morty-master, pyro-master and rocko-master. Only remaining item is updating the code at the OE-Patchwork server for the changes to be live. [1] http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/commit/?h=staging&id=18d932de23f413206b8c44fbeb137d148cee58fe
I'd like to know where we got to with this - were we waiting for a window of Michael's time or was there some other blocker?
(In reply to comment #10) > I'd like to know where we got to with this - were we waiting for a window of > Michael's time or was there some other blocker? Yes, only missing item is/was to update the production and master branches with the mentioned commit in branch staging (comment 9). Not sure if that would cleanly merge today, but most likely yes.
Question Answered
Bulk move from 4.99 or 0.00 to 5.99
We don't have a fork of patchwork anymore, and there's a related upstream ticket: https://github.com/getpatchwork/patchwork/issues/22.