Hi Tracy, On Thu, 2013-09-26 at 22:01 +0000, Graydon, Tracy wrote: > The New Model > > - Images are generated for both OBS projects. > - We still cherry-pick changes for Release and use "normal" acceptance > process for Tizen:IVI
On git level, cherry pick is about picking a specific patch out of a queue of inter-dependent patches. Cherry-pick sometimes requires some manual work, because of patch dependencies. Now, on your level, you work with SRs. An SR is basically, roughly speaking, an tarball for you. You see a big diff from the previous tarball you accepted, and the changelog I wrote for you. Correct me if I am wrong. So now, we are in the release stage. This basically means branching. We branch out the release, kind of freeze it, and only take critical fixes in. Let's refer the main trunk, where we branched from, just "trunk". And I never understood why and how you are trying to organize this process on your level, without directly imposing this process to maintainers. I never understood how you scale for this, and how this could possibly be done correctly. Probably now it is time to ask :-) So, I maintain kernel-x86-ivi. The only branch I have is "tizen". This branch corresponds to the trunk. I can send SRs to you from this branch. Now, I have a bunch of clean-ups and other "noise" patches in the "tizen" branch. And I've made a critical fix. How am I supposed to send this fix to you? Do I send it along with with the noise? Probably not? Do I send it alone? From the tizen branch? Should I then "temporarily" rebase it? What do you mean by "I'll cherry-pick"? If I send you both fix + noise, you cannot possibly separate the noise out, and you should not, right? So what are you going to cherry-pick? Why don't you we just have another branch which maintainers can use to send you release SRs? E.g., "release" branch. This "copy SRs between OBS project" sounds like something which is error-prone, manual, and not very scalable... Why not to let _maintainers_ separate things, and send you directly to the release or trunk queues. Why not to make _maintainers_ to be responsible for sending only critical things to the release queue. All you'd need to do is to make sure they do send important stuff, and then accept or decline. I do not really see any place for "copying" in a well-design process. I am sure I am confused somewhere, please, correct me where I am wrong. Thanks! -- Best Regards, Artem Bityutskiy _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
