Right, we should not require contributors to also merge down to stable
("beggars can't be choosers" ;) ).Devs should that, and whether it's the dev who committed, or a dev who periodically sweeps, can be worked out over time. But Uwe should lay down the law :) Eg, we should always use "svn merge" so the merge props are properly tracked, so that periodic sweeping is straightforward. Mike On Mon, Apr 26, 2010 at 11:25 PM, Shai Erera <[email protected]> wrote: > My understanding is that "Joe Contributor" will not be forced to prepare a > patch against "stable", but will be appreciated if he does :). > > The mechanics for "Joe Committer" is undecided yet. What's clear is that Joe > cannot say "I don't care about stable for this issue, therefore I cannot > backport it". The decision on backporting will be done per issue/patch. > Whether it will be backported immediately (as part of that issue), or later > on as part of a periodic stable/trunk sync, is undecided yet. > > A minor correction: >> >> they do stable or vice versa > > there is no "stable or vice versa" - everything must be put on trunk (unless > it really doesn't belong there, because e.g. the API no longer exists). Many > things will most likely get backported to stable. > > Shai > > On Tue, Apr 27, 2010 at 12:46 AM, Grant Ingersoll <[email protected]> > wrote: >> >> +0.9 >> >> What are the requirements of me, "Joe Committer" and of "Joe Contributor" >> in regards to submitting/committing patches? >> >> For Joe Committer, am I required to put everything on stable and trunk or >> can I just pick trunk and if someone else wants it they do stable or vice >> versa? >> >> Likewise for Joe Contributor, must I generate two patches now? >> >> >> On Apr 26, 2010, at 3:06 PM, Michael McCandless wrote: >> >> > This is exactly the intention behind the proposal we are voting on. >> > >> > Big changes, that'd be destabilizing if attempted on the stable >> > branch, would be done only on unstable (= trunk). >> > >> > More "normal" changes, which can still include deprecations/some back >> > compat, would be done on the stable branch and unstable. >> > >> > So, eg, rather than attempt back compat for a big change like flex, we >> > would instead do it only in unstable and it'd first become "available" >> > in the next .0 release. >> > >> > By segregating the big changes away from stable we should be able to >> > keep stronger back compat on stable. We also save our resources not >> > building costly back compat layers that, because of their complexity, >> > bring their own problems. Also, our release numbers are more >> > "standard" -- the .0 release will have major changes (unlike today >> > where is has no changes except removal of deprecations). >> > >> > Mike >> > >> > On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <[email protected]> >> > wrote: >> >> On 4/26/10 2:43 PM, Chris Hostetter wrote: >> >>> >> >>> My best guess: that what this is really suggesting is that "trunk" >> >>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0, >> >>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; >> >>> 4.1., >> >>> 4.2, etc...) happen on "more stable" branches off of the major version >> >>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release, >> >>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...) >> >> >> >> This is what I would like. Not sure if that's what will come from the >> >> current proposal or not, but seems so to me. >> >> >> >> -- >> >> - Mark >> >> >> >> http://www.lucidimagination.com >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
