Am 25.10.2017 um 19:44 schrieb Marcus: > Am 25.10.2017 um 01:00 schrieb Patricia Shanahan: >> >> On 10/24/2017 2:34 PM, Kay Schenk wrote: >>> >>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote: >>>> I'm starting a short series of occasional posts to capture the >>>> current collective state of mind on the next release. I'll float >>>> them here for refinement or lazy consensus, and then we may want to >>>> reuse this text in wiki or blog posts to avoid repeating the same >>>> concepts over and over. >>>> >>>> Let's start with branches. >>>> >>>> We all wish 4.1.4 to be the last 4.1.x release. >>>> >>>> We currently have an AOO415 branch at >>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this >>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The >>>> AOO415 branch will result in a release ONLY if we have some >>>> important bug fixes to release and trunk is not ready yet. No new >>>> features, even small enhancements, are added to it. No commits to >>>> AOO415 happen without appropriate mailing list discussions (dev or >>>> security, depending on cases). >>>> >>>> Trunk is where all development happens. It will be branched for a >>>> new release (like, an AOO420 branch - name still provisional) when >>>> the code is mature: beta or even RC. Until then, we simply keep >>>> working on trunk as we are doing now. >>>> >>>> In case we need to commit to a branch, any changes are still >>>> committed to trunk first and then merged to branches using SVN >>>> merge in all situations when this is possible (i.e., when there are >>>> no merge conflicts). The mergeinfo for AOO414 and AOO415 isn't >>>> clear, so we'll have to make sure that trunk contains all fixes >>>> done there (or equivalent in case of conflicts) and, done that, we >>>> commit to AOO415 only if: >>>> 1. The fix is important and agreed upon on the relevant list >>>> 2. The commit is done with "svn merge" starting from a trunk commit >>>> >>>> This will ensure that we can shift the focus to trunk while still >>>> keeping a branch that remains ready for a quick release if needed. >>>> If we are never in this situation, the next release will be from >>>> the current trunk and AOO415 will never result in a release. >>>> >>>> Regards, >>>> Andrea. >>> >>> Would it be more clear to just remove the AOO415 branch and only >>> re-instate it if needed (hopefully not). I don't see anything in >>> AOO415 that wasn't included in AOO414. >>> >> >> The decision to keep the 4.1.5 branch around came out of a discussion on >> the security mailing list. The potential problem is that someday we may >> be faced with a bug for which we need to get a fix out into the field as >> soon as possible. >> >> Because of the sheer size of AOO, it takes time to get set up for a >> release. The idea is to do as much as we can to prepare without >> committing to a release. I have a check-out of AOO415 built. As the >> version number changes get incorporated I'll update and rebuild. Not >> having to wait for the branch to be prepared, check it out, and do a >> full build reduces by about a day the time it would take from knowing a >> fix to having it built, tested, and checked in. >> >> I would like to make this an on-going policy. As soon as we ship 4.2.0, >> we remove the AOO415 branch but create AOO421, identical except for >> version numbers to AOO420, ready in case of an emergency fix. > > +1 > This is an good and cheap idea to speed things up. > > Marcus
To be prepared we should now complete the missing steps to make the 415 branch ready. I am not sure if only the release manager is allowed to do it? Matthias > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
smime.p7s
Description: S/MIME Cryptographic Signature
