X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Fri, 1 Jan 2016 22:59:41 -0500 From: al davis To: geda-user AT delorie DOT com Subject: Re: [geda-user] Merging stuff. How to make it happen Message-ID: <20160101225941.6ed5eff1@floyd.freeelectron.net> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Fri, 1 Jan 2016 17:30:07 -0900 "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" wrote: > I stopped by the last sprint briefly and asked about this. It sounds like > there's no definite policy for deciding when to merge things. I therefore > propose that the following conditions should always be considered > sufficient for a merge into the main devel branch: > > * the person who wrote it says it's ready > * at least one other person has looked at the patch > * devel fixed or addressed any issues raised > * it doesn't remove any functionality > * it doesn't do anything known to be contentious That brings up one of the reasons for gnucap plugins. I see a lot of projects turn into a mess due to a haphazard merge policy. In Gnucap .. The "master" branch is considered stable. It is never changed directly. The only change is for the "unstable" branch to become master. When the "unstable" branch has been shown to be ready, and has been stable for a month or two, it goes to "master". The "unstable" branch is kind of like master candidate. It too is never changed directly. The only changes are for some other branch to be pushed to unstable. Other branches are working branches, in various states. Each one has a purpose. That might be somebody's hack branch, or branches for specific changes. For a branch to be considered for merge, it must differ from unstable such that the only difference is that which is being proposed for merge, so it can be "fast-forward" merged into unstable, the same as it becomes the "unstable" branch. It is discussed on the list, for essentially the 5 points Britton mentioned. Also, there must be test cases that demonstrate proper operation, and code coverage. Once merged, it is the responsibility of whoever is preparing another branch for merge to "rebase" to the new "unstable". Without a policy like this, the project can turn into a big mess, or the people trying to merge can spend a lot of time resolving conflicts. In my experience, usually when "the person who wrote it says it's ready", it isn't. It's common for people to start on something, get it mostly working, then move on never really finishing it. So I look at it, run the tests, and usually make some changes, to that branch. Then push to unstable, or not, if it really isn't ready. The policy for plugins is different. There is another repository for plugins not distributed with the main program but still distributed and available. For those, "the person who wrote it says it's ready" is all that is needed.