On 11/02/2015 18:27, Gregory Farnum wrote: > On Wed, Feb 11, 2015 at 8:42 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: >> Hi Ceph, >> >> Yesterday the dumpling & giant backport integration branches were approved by Yehuda, Sam and Josh and were handed over to QE. An interesting discussion followed and it revealed that my understanding of the intended workflow was significantly wrong. It took me a while to figure out something that makes sense. There is a good chance that I'm wrong again, please speak up :-) >> >> The workflow proposed a month ago was the following: >> >> 0. Developer follows normal process to land PR to master. Once complete and ticket is marked Pending Backport this process initiates. >> 1. I periodically polls Redmine to look for tickets in Pending Backport state and focus on the ones that are left unattended for too long >> 1a. Under the supervision of the author of the original patch, I find the commits associated with the Redmine ticket and Cherry Pick to the backport integration branch off of the desired maintenance branch (Dumping, Firefly, etc). >> 1b. I resolve any merge conflicts with the cherry-picked commit >> 2. I merge all backports for a given branch in an integration branch >> 3. I ask the leads of each project to review the integration >> 4. Once satisfied with group of backported commits to integration branch, I notify QE. >> 5. QE tests backport integration branch against appropriate suites >> 6a. If QE is satisfied with test results, they merge backport integration branch. >> 6b. If QE is NOT satisfied with the test results, they indicate backport integration branch is NOT ready to merge and return to me to work with original Developer to resolve issue and return to steps 2/3 >> 7. Ticket is moved to Resolved once backport integration branch containing cherry-picked backport is merged to the desired mainteance branch(es)-- >> >> I think it should be modified to something like the following: (I have the role of "the backporter"): >> >> 0. Developer follows normal process to land PR to master. Once complete and ticket is marked Pending Backport this process initiates. >> 1. A cron job updates an inventory of the backports for each branch (see http://workbench.dachary.org/ceph/ceph-backports/wikis/firefly for instance) > > How's it updating that inventory? I wrote a script that does cross referencing and writes this page. It's been a precious tool for me to not get lost ;-) It is still in a state of flux http://workbench.dachary.org/dachary/ceph_workbench and will solidify each time I use / update it. > >> 1a. The PR does not require integration (e.g. it changes the qa directory), it is merged in the release branch (dumpling, firefly, etc.) by the reviewer > > Who are you expecting to create backport PRs? Way back when I thought > that you were assembling branches and PRs based on tickets in the > "Pending Backport" state, but now that looks not to be the case. Sometime the developer does spontaneously. Sometime the developer marks the "backport" field in the ticket and forgets about it. Then I look at the backport, try to do it myself and if I can't I ask the developer (kindly ;-) if he has time to do it. Sometime the developer will ask me "that needs backporting" and I'll update the tickets and try to backport successfully and only report back to the developer when the test results come back green or red (that happened with ~15 backports for rgw). Sometime the lead tells me : we can't release this, we need to backport this issue (that happened with rbd and Jason quickly backported the missing issue because it was the last piece of the puzzle). >> 1b. The PR requires integration and the label "needs-qa" is added to it by the reviewer. > > I thought the needs-qa label was a flag that it should go into a > master integration branch (wip-sam-testing, wip-sage-testing, w/e); > aren't the milestone LTS labels sufficient to indicate they should be > tested in integration? The "needs-qa" has no meaning when it comes to stable branch releases, that's why I proposed to use it. The purpose is essentially the same. There is a need to distinguish between PR that needs integration and the others. For instance the tests suite patches that you merged in dumpling do not need qa and you merged them directly. If there is no label to distinguish between the two, there will be confusion and tools cannot be written to pick the "needs-qa" PR. > >> 2. If the inventory page shows PR that are pending integration >> 2a. The backporter merges them in the dumpling-backports, etc. integration branch >> 2b. The backporter runs the rados, rgw, rbd etc. suites on the integration branch (if no rgw backports are present, rgw suite can be skipped etc.) >> 2c. The backporter sorts and analyzes the test results, asking the developer if necessary >> 2d. If a problem is found on a PR, the backporter removes the "needs-qa" label from the PR and makes sure the developer is aware that integration failed and why >> 2e. The PR successfully integrated are merged into the dumpling, firelfy, etc. branch >> 3. A cron job runs various suites on the dumpling, firefly, etc. branches (AKA "the nightlies") >> 3a. The nightlies send reports to the ceph-qa list when a suite completes >> 3b. The leads of each component are responsible for analyzing and updating tracker.ceph.com accordingly > > Mmm. I'm happy to look at suites that get run this way but I'm > unlikely to notice them go by on the list if I'm not poked about them > — I generally filter out anything that has a person's name in it or > whatever. Ok. Do you look into the results for fs produced by the nightlies for the stable branches ? Cheers > -Greg > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
