X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TK9yHD76Cj+yJZEt7sqjkIlQ7K5hlqFberax9oq/Dqc=; b=LtOmTeYfhHKn2rrSpp+VJvULskYV+9WjVtXdKzMOIz/fnznkiZIV6gdHuz50uxcHo7 l7S7uPw0Gk1Bdj3UUDWdaWAxMc4IRt++/XYP0b1bnawIfZ6WFX6PyGDA0xCEoawhxfp7 d8+a/sa8J9XRSD5volQ5cxiN3hz+t7qcyuc5NY9fdhaWXgvSG8MmIgx9q0z2BXYxxNcb aWVwUo2LJi+LcUNkQOzHXkrLke+IfuB7PmWmzrxtUPwVEJkHFW/mf6vsed6FTC4qBVRJ cGAZccEgeh9mqWE/01DFiwpvnDrK4yaGaJIkib9GCMu6nI8T1LAps57ubUrcpPO73Wo2 RLCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=TK9yHD76Cj+yJZEt7sqjkIlQ7K5hlqFberax9oq/Dqc=; b=YXyI/9DHmn21Nop0sAK/4TOU4ibvt7LiMc+MNIDb2x8WnslmS6ZeYNTIzxfglg7QiC DGfsnk39BhPHT5WPuPz52efW8PESRIzVFvlFGUdF3AUydEHiDenBtlaMkUaI1MlP2AH5 3GNPnyeiSaAZncBVvMNmagGT/1+Hv0oWjFtMBokJPbezoE9AfFLFqu8aJxJsTGSVhK1s 8/cCyi3KRuX136uPsrrzrOItW/ctw/ELUXitd2LTeNN2Ky8Ry89+/hvx+YCuPGSHxVKD pmo8LEXFL/3h6V1QcmBC1EipkWQ1/kXlTgvKoBHVVypfkCR14dwsYaus+/7gJCHe8hEQ DoDg== X-Gm-Message-State: AG10YOTaYWOgi7Hw+uKeu30fobVP2HxojIaOfG+hduFxda3N10YZebrkC4s6g3Hyl58r3sTg7Ph77fMcymRbgQ== MIME-Version: 1.0 X-Received: by 10.28.90.133 with SMTP id o127mr6578075wmb.101.1454534219291; Wed, 03 Feb 2016 13:16:59 -0800 (PST) Date: Wed, 3 Feb 2016 12:16:59 -0900 Message-ID: Subject: [geda-user] unstable_master branch From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 Reply-To: geda-user AT delorie DOT com This got discussed previously and there didn't seem to be any major opposition, so I'd like to elevate it to formal proposal. The idea is to have a branch where we merge new work, allowing devs to test each others branches more easily and automatically and work off their own branches without having to juggle things between branches, while still maintaining master in a release-ready state. How it should work (IMO): 1. same people in charge of merging into it. They have a long history of project stewardship and this isn't intended as an end-run around their authority 2. about the same criteria for merge as now, maybe only a little bit more aggressive and trusting of individual devs. devs should understand that a merge into unstable_master isn't a free pass into master: in fact if it causes trouble in unstable_master the odds of getting into master go down, not up. 3. Working things are eventually merged into master in the same order they were applied to unstable_master. 4. always merge, never rebase. This makes 3 much easier and preserves an accurate history. In the past there's been an inclination to rebase, but it's not really needed for a project of pcb size. Peter Clifton indicated that after consultation with another long-standing dev who favored merge, he would support merging everything, even trivial branches. Britton