Adam and Vincent, I fully understand and appreciate your suggestion. The real question is how to handle major code refactoring that affects all barclamps (in this case OS ones). Testing of refactoring takes a long time (multiple days). Every time a change happens to any barclamp the long poll testing needs to be restarted.
I am aware of 3 ways to proceed. One, is to be able to break refactoring into smaller pieces. (This is what we tried to do with database barclamp refactoring. But we were not successful with running both database and MySQL barclamps concurrently.) That would allow all work to proceed without blocking. Second, to complete refactoring testing without changing any barclamps under it. Third, to merge it as is and fix consequential breakage. I am completely open to any suggestion, except for repeated testing of database refactoring for any change in OS barclamps. Thanks, Arkady -----Original Message----- From: crowbar-bounces On Behalf Of Vincent Untz Sent: Monday, June 03, 2013 4:18 PM To: crowbar Subject: Re: [Crowbar] status and merge orchestration Le lundi 03 juin 2013, à 15:55 -0500, arkady_kanev...@dell.com a écrit : > Vincent, you cannot have both database and MySQL barclamps at the same time. > All OS barclamps are dependent on MySQL. > And we need to do the whole change to database one in one swoop. I know, and I said I understand the switch to the database barclamp is a one-time project-wide switch (and also said I'm fine with this ;-)). What I'm disagreeing is that after this, other SUSE-related patches still get blocked on the community branch because we're suffering from that; and I don't understand the need to block this while branching can make everyone happy. Let me illustrate this: - C is community branch - D is dell branch - 1, 2, 3, etc. are commits - I assume that Dell is interested in commit 1, but not in the other ones We can have the following: C | 1_ | \ 2 D | | 3 ... or: C_ | \ 1 D | | 2 1 (cherry-picked from C branch) | 3 or even: C_ | \ 2 D | | 1 | | 1 (cherry-picked from C branch) 3 git cherry-pick is a very powerful yet simple tool. > The goal is have all changes in Pebble. > If we (all parties) work in their private repos we lose community. I'm certainly not suggesting people move to their private repos. On the contrary, I'm suggesting that we unfreeze the community branch to help the community, and have freezes in the private repos instead. Vincent -- Les gens heureux ne sont pas pressés. _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/ _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
