On 10/02/2015 19:25, Gregory Farnum wrote: > On Tue, Feb 10, 2015 at 10:04 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: >> >> >> On 10/02/2015 18:29, Yuri Weinstein wrote:> >>> On 10/02/2015 18:19, Yuri Weinstein wrote:> >>>> Loic, >>>> >>>> The only difference between options if we run suits on merged dumpling vs dumpling-backports first - is time. >>>> We will have to run suites on the final branch after the merge anyway. >>> >>> Could you explain why ? After merging dumpling and dumpling-backports will be exactly the same. >>> >>> Loic - I feel that finial QE validation should be done on the code that gets actually released to customers, e.g. dumpling branch after the merge. I do see your point about branches being identical and ready to change my mind if you insist. Does my reasoning make sense? Please advice, how we should proceed. >> >> The dumpling-backports branch currently is at >> >> https://github.com/ceph/ceph/commit/3944c77c404c4a05886fe8276d5d0dd7e4f20410 >> >> after a successful test run from QE and a merge into dumpling, the dumpling branch will be at >> >> https://github.com/ceph/ceph/commit/3944c77c404c4a05886fe8276d5d0dd7e4f20410 >> >> as well. In other words they are identical and there is no point in running a test again. The only reason why they could be different is if a commit is inadvertently added to the dumpling branch while testing happens on the dumpling-backport branc. In this case the presence of this new commit would be reason enough to run another round of test indeed. So the process could be: >> >> If tests are ok and merge can fast forward, then release. >> If tests are ok and merge cannot fast forward, send back to loic because a commit was added by accident and needs to be approved by the leads. >> >> If testing happens on the dumpling branch, adding a commit to the dumpling branch would have side effects that could taint the results of the tests or, even worse, go unnoticed. There is zero chance that someone adds a commit to the dumpling-backports branch and that gives us something stable. On the contrary, the odds that someone adds a commit to the dumpling branch are high, specially if the tests take a few weeks to complete. >> >> As Greg mentioned, merging in dumpling does not matter much for this round because it is what has been done in the past. And to be honest, I would not mind if an additional commit taints the process by accident. However, unless there is a reason not to, it would be good to establish a process that is solid if we can. >> >> I've witnessed Alfredo's pain on each release and an additional benefit of having a dumpling-backports branch that nobody tampers with just occured to me. When and if QE finds that dumpling-backports is fit for release, instead of merging it into dumpling it could be handed over to Alfredo for release. And he would be able to proceed knowing it is stable and won't be moving forward. Once the release is done and the tag set to the proper commit, the dumpling branch can be reset to dumpling-backports. If commits were added during the process, their authors could be notified that they were discarded and need to be merge again. That would not work for the master branch but it would definitely be possible for the stable branches because such "out of process" commits are rarely added. >> >> I've not thought this through, but the more I think about it the more I like the idea of using dumpling-backports as a staging area until the release is final. > > What's the purpose of even having a dumpling branch at that point? > We're not using it for anything under your model. The dumpling branch is where the point release are published. The dumpling-backports branch is where the point release are developed and tested. > > Now, as it happens there are some reasons to maintain a dumpling > branch that isn't part of backports. We've been doing a lot of work > lately to make the nightlies behave well under RHEL and in various > other environments, which sometimes involve changing the tests > themselves. That can mean updating the ceph.git/qa/workunits in our > LTS branches, which I've done a few times over the last couple of > months. Since they're used for testing they aren't suitable for going > through a backports workflow, we just want them to get into the > nightlies as fast as possible. Tossing out any such work every time a > point release appears would be irritating, to say the least. > (We could also pull the workunits out of ceph.git, but that's a > different discussion.) This is a good point. I'm assuming backports rely on the dumpling branch of ceph-qa-suite. And if a change needs to be done in ceph-qa-suite for the benefit of an ongoing backport effort to publish a point release, it will have to be done in such a way that it can work for both the current dumpling and the future point release. Am I understanding you correctly ? Cheers > -Greg > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
