From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: ESR's intimidatingly huge task list Date: Sat, 11 Jan 2014 19:46:08 +0200 Message-ID: References: <20140111165635.D683C3803A6@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11364106e842e404efb56acd X-Trace: ger.gmane.org 1389462371 11453 80.91.229.3 (11 Jan 2014 17:46:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 17:46:11 +0000 (UTC) Cc: emacs-devel To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 11 18:46:20 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W22dX-00082j-Px for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 18:46:20 +0100 Original-Received: from localhost ([::1]:34987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W22dX-0006oo-9B for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 12:46:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W22dQ-0006jw-OF for emacs-devel@gnu.org; Sat, 11 Jan 2014 12:46:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W22dN-00015u-WE for emacs-devel@gnu.org; Sat, 11 Jan 2014 12:46:12 -0500 Original-Received: from mail-ob0-x22a.google.com ([2607:f8b0:4003:c01::22a]:62533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W22dN-00015l-Mo for emacs-devel@gnu.org; Sat, 11 Jan 2014 12:46:09 -0500 Original-Received: by mail-ob0-f170.google.com with SMTP id uy5so4193755obc.1 for ; Sat, 11 Jan 2014 09:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9mNzv2Ja5+/r0N/ChPKlQ6CKkkoe+SY21tL1p9pg+ZM=; b=DkgRYcZAQzQUwmDu6c/d1olIumYYA/C3E/OTvKHRIE05lKgMGHRmEtJkz4tG7Da60a IgujziS1YnXN/J26mCPZgS+VfnbhqLcJYvz7GX/Q4vxawsTjd441yWbeRrdje4uYhryG Gmcme5fMJnJaowUQ9phhqcusY76YT5Wa0r8GZ9ng7RVvVlB+g1Vqtm5W/11FZ+Rld/ap uP0/xcWvCHZ3uEb8cvOoJHVmexOR85UzTR36Rd7scSRVlhDu3FRYuAeSucZlieasS2sY mQuarHT07OK/kr0M6ymTQzvU3nI/lSs/ZC1ciBYqah2U2hVYukig13wcgRCcqcpx1+wD Ev0Q== X-Received: by 10.60.231.164 with SMTP id th4mr9387850oec.26.1389462368566; Sat, 11 Jan 2014 09:46:08 -0800 (PST) Original-Received: by 10.76.109.98 with HTTP; Sat, 11 Jan 2014 09:46:08 -0800 (PST) In-Reply-To: <20140111165635.D683C3803A6@snark.thyrsus.com> X-Google-Sender-Auth: o-Tz1fjgnjThN6UDTUicc9e6doU X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168097 Archived-At: --001a11364106e842e404efb56acd Content-Type: text/plain; charset=UTF-8 One small task that wasn't mentioned is updating .gitignore to match to .bzrignore file. Currently there's lots of stuff in the .bzrignore that's not in the .gitignore. On 11 January 2014 18:56, Eric S. Raymond wrote: > *gulp* > > In order not to lose track of things, I just put together a complete > list of my pending tasks related to the git transition, /etc cleanup, > and VC. It follows. > > Bear in mind this is *after* I've been working these problems for five > days straight. I'm concentrating on this full-time (hacker full time, > not mere 9-to-5) and still I expect there's a solid two weeks of work > here, maybe more. > > Please try to be cooperative. If you see one of these tasks you can > pick off or make unnecessary, do it. > > Pre-git-transition: > > * Tag cleanup is unfinished. > > I believe the following tags were created as temporary markers during > feature branch work and ceased being interesting when the feature > landed in trunk: > > after-merge-gnus-5_10 > amigados-merge > before-merge-emacs-app-to-trunk > before-merge-gnus-5_10 > before-merge-multi-tty-to-trunk > before-merge-unicode-to-trunk > before-miles-orphaned-changes > before-remove-carbon > before-remove-vms > before-thomas-posix1996 > emacs-unicode-2-pre-sync > gnus-5_10-post-merge-josefsson > gnus-5_10-post-merge-yamaoka > gnus-5_10-pre-merge-josefsson > gnus-5_10-pre-merge-yamaoka > merge-multi-tty-to-trunk > merge-unicode-to-trunk > remove-carbon > remove-vms > > The following tags have owners who have claimed them. > > ttn-vms-21-2-B2 > ttn-vms-21-2-B3 > ttn-vms-21-2-B4 > v0.1 > v0.1.0 > v0.1.1 > v0.1.2 > v0.1.3 > v0.2.0 > v0.3.0 > > Disposition of the EMACS_PRETEST* tags awaits a maintainer decision on > whether we will continue to use pretest tags. The following bzr tags > are also in this category: > > emacs-24.0.96 > emacs-24.0.97 > emacs-24.2.90 > emacs-24.2.91 > emacs-24.2.92 > emacs-24.2.93 > emacs-24.3-rc1 > > I do not have a disposition for the following tags: > > Release_5_25 > lisp-bob > release-0-0 > release-0-1 > release-1-0 > root-libc-2_0_x-branch > sml-mode-6.0 > sml-mode-6.1 > unicode-post-font-backend > unicode-pre-font-backend > v1_7i > v2007-Sep-10 > xwidget-0.2 > > * Change lisp/version.el and Makefile.in so build is fully working > from a git repo. See the it version of a version getter at > http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00430.html > > * Lift bzr references in the git repo. Substeps: > > 1. Commits to bzr and git repos are temporarily closed. > > 2. I clone the Savannah git repo. > > 3. I signal for a reset of the Savannah git repo to empty. > > 4. I apply a pre-built reposurgeon script fixing the references. > > 5. I push the altered repo to the empty repo on Savannah. > > 6. Commits are opened again. (The commit-mirroring from bzr > will not care that the git repo has been altered.) > > * Add language to the hacking guides about using VCS-independent > action stamps or references by content, rather than git hashes, > in commit comments. > > * Create an Emacs GPG identity and use it to cryptosign release tags. > (Reference lifting must happen first.) The following release tags, at > minimum, should be replaced with cryptosigned annotated tags. > > emacs-19.34 > emacs-20.1 > emacs-20.2 > emacs-20.3 > emacs-20.4 > emacs-21.1 > emacs-21.2 > emacs-21.3 > emacs-22.1 > emacs-22.2 > emacs-22.3 > emacs-23.1 > emacs-23.2 > emacs-23.3 > emacs-23.4 > emacs-24.1 > emacs-24.2 > emacs-24.3 > > * Add a recipe for cryptosigning to the Emacs release procedure. > > * Better cross-VCS integration of smerge in vc.el. Here are Stefan's > requirements: > > - Improve vc-git.el so that it can automatically enable smerge-mode when > opening a conflicted file and (probably conditional on a config var) > mark the file as "not conflicted any more" when saving with no > remaining diff3 markers. > This currently works in vc-bzr.el (and vc-svn.el as well, IIRC). > > - Improve vc-git.el with vc-git-conflicted-files so that > vc-find-conflicted-files works for Git as well. > > * Work with hydra-users mailing list to update hydra build config. > > * Christopher Schmidt said: > > > Please examine this list of tag names, I want to know which > > should be thrown out to reduce clutter. > > [...] > > v0.1 > > v0.1.0 > > v0.1.1 > > v0.1.2 > > v0.1.3 > > What objects does these tags point to? These might be some > leftovers of a failed merge of a package of mine from my git > repo to the (back then) bzr elpa branch of the repository. If > so, please drop them. > > Must follow through on this. > > * Eli Zaretskii writes: > > > Which reminds me: what about the "fixes bug" field of the commit > > metadata? are they copied into the git repo? If so, how can I > display > > them in git? > > * Eli Zaretskii has some to-dos about the Emacs wiki: > > . The section about merging to the upstream master seems to omit "git > push" after merging the task onto the master branch. It ends with > the "git commit" command, which AFAIK is not the end of the story. > > . The few places that describe a merge from another branch seem to > say that one needs to issue 2 commands: "git merge" and "git > commit". > Perhaps I'm confused, but isn't it true that "git merge" > automatically commits if there are no conflicts? If I'm right, an > explicit commit is needed after merge only when there are conflicts > to be resolved. > > For the same reason, is "git revert" TRT when a push upstream fails > after a merge from the local task branch, because someone else > pushed meanwhile? The merge is already committed locally, so what > will revert do? I think one will need "git reset" in this case. > > . I would suggest describing the setup of git-merge-changelog, > because as long as we keep ChangeLog files in the repository, > people might bump into conflicts in the logs, and it would be nice > to avoid that. > > . I think we should discuss some more how to work with the > development trunk and the release branch in parallel, and reflect > the results of the discussion in the Wiki. > > The issue here is that the release branch and the trunk diverge > very quickly after the branch point, and the result is that after > you checkout the other branch, you generally need a very long > build, many times a full bootstrap. While on a modern system, a > full bootstrap should take a few minutes, it is still annoyingly > long, and makes higher the risk of losing the race against other > committers. In addition, you only have a single executable at any > given time, so comparison of behavior between the two branches is > difficult. > > So perhaps we should find a way of having two separate branches, > such that switching between them does not require a build if > nothing changed. > > Some of these are easy tasks. Some of them are research papers. > > Git transition: > > 1. Wait on 24.4 release and Stefan's go signal. > > 2. Andreas announces on the dev list that the changeover is beginning. > b > 3. Andreas turns off bzr commit mirroring (and disables the bzr repo). > > 4. Andreas enters a small documentation commit recording the changeover. > > 5. Andreas installs a commit hook that mails notifications to the > emacs-diffs > mailing list. (This could be done sooner without disruption.) > > 6. Andreas repacks the repo. (This could be done sooner without > disruption.) > > 7. Andreas announces on the dev list that the git repo is live for > developer pushes. > > 8. Someone updates http://savannah.gnu.org/projects/emacs/ to reflect the > change > > 9. I mark the wiki pages on Bzr obsolete and update the Git ones. > > 10. I will do the work required to update root and /admin to reflect > git use over the following few days. (/etc is clean already.) In > root, Makefile.in refers to a bzr file and that's it. > > /etc cleanup: > > 1. Remove /etc/JOKES (but save the EMACS acronyms) > > 2. Compile a list of suggested dispositions for every file in /etc (keep, > delete, move to new directory) > > 3. Implement 2 after list review. > > Asynchronously: > > 1. VC has these known bugs: > > http://debbugs.gnu.org/8288 > http://debbugs.gnu.org/8756 > http://debbugs.gnu.org/15696 > http://debbugs.gnu.org/10378 > -- > Eric S. Raymond > > Such are a well regulated militia, composed of the freeholders, > citizen and husbandman, who take up arms to preserve their property, > as individuals, and their rights as freemen. > -- "M.T. Cicero", in a newspaper letter of 1788 touching the > "militia" > referred to in the Second Amendment to the Constitution. > > --001a11364106e842e404efb56acd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One small task that wasn't mentioned is updating .giti= gnore to match to .bzrignore file. Currently there's lots of stuff in t= he .bzrignore that's not in the .gitignore.


On 11 January 2014 18:56, Eric S. Raymon= d <esr@thyrsus.com> wrote:
*gulp*

In order not to lose track of things, I just put together a complete
list of my pending tasks related to the git transition, /etc cleanup,
and VC. =C2=A0It follows.

Bear in mind this is *after* I've been working these problems for five<= br> days straight. =C2=A0I'm concentrating on this full-time (hacker full t= ime,
not mere 9-to-5) and still I expect there's a solid two weeks of work here, maybe more.

Please try to be cooperative. =C2=A0If you see one of these tasks you can pick off or make unnecessary, do it.

Pre-git-transition:

* Tag cleanup is unfinished.

=C2=A0 =C2=A0 I believe the following tags were created as temporary marker= s during
=C2=A0 =C2=A0 feature branch work and ceased being interesting when the fea= ture
=C2=A0 =C2=A0 landed in trunk:

=C2=A0 =C2=A0 after-merge-gnus-5_10
=C2=A0 =C2=A0 amigados-merge
=C2=A0 =C2=A0 before-merge-emacs-app-to-trunk
=C2=A0 =C2=A0 before-merge-gnus-5_10
=C2=A0 =C2=A0 before-merge-multi-tty-to-trunk
=C2=A0 =C2=A0 before-merge-unicode-to-trunk
=C2=A0 =C2=A0 before-miles-orphaned-changes
=C2=A0 =C2=A0 before-remove-carbon
=C2=A0 =C2=A0 before-remove-vms
=C2=A0 =C2=A0 before-thomas-posix1996
=C2=A0 =C2=A0 emacs-unicode-2-pre-sync
=C2=A0 =C2=A0 gnus-5_10-post-merge-josefsson
=C2=A0 =C2=A0 gnus-5_10-post-merge-yamaoka
=C2=A0 =C2=A0 gnus-5_10-pre-merge-josefsson
=C2=A0 =C2=A0 gnus-5_10-pre-merge-yamaoka
=C2=A0 =C2=A0 merge-multi-tty-to-trunk
=C2=A0 =C2=A0 merge-unicode-to-trunk
=C2=A0 =C2=A0 remove-carbon
=C2=A0 =C2=A0 remove-vms

=C2=A0 =C2=A0 The following tags have owners who have claimed them.

=C2=A0 =C2=A0 ttn-vms-21-2-B2
=C2=A0 =C2=A0 ttn-vms-21-2-B3
=C2=A0 =C2=A0 ttn-vms-21-2-B4
=C2=A0 =C2=A0 v0.1
=C2=A0 =C2=A0 v0.1.0
=C2=A0 =C2=A0 v0.1.1
=C2=A0 =C2=A0 v0.1.2
=C2=A0 =C2=A0 v0.1.3
=C2=A0 =C2=A0 v0.2.0
=C2=A0 =C2=A0 v0.3.0

=C2=A0 =C2=A0 Disposition of the EMACS_PRETEST* tags awaits a maintainer de= cision on
=C2=A0 =C2=A0 whether we will continue to use pretest tags. =C2=A0The follo= wing bzr tags
=C2=A0 =C2=A0 are also in this category:

=C2=A0 =C2=A0 emacs-24.0.96
=C2=A0 =C2=A0 emacs-24.0.97
=C2=A0 =C2=A0 emacs-24.2.90
=C2=A0 =C2=A0 emacs-24.2.91
=C2=A0 =C2=A0 emacs-24.2.92
=C2=A0 =C2=A0 emacs-24.2.93
=C2=A0 =C2=A0 emacs-24.3-rc1

=C2=A0 =C2=A0 I do not have a disposition for the following tags:

=C2=A0 =C2=A0 Release_5_25
=C2=A0 =C2=A0 lisp-bob
=C2=A0 =C2=A0 release-0-0
=C2=A0 =C2=A0 release-0-1
=C2=A0 =C2=A0 release-1-0
=C2=A0 =C2=A0 root-libc-2_0_x-branch
=C2=A0 =C2=A0 sml-mode-6.0
=C2=A0 =C2=A0 sml-mode-6.1
=C2=A0 =C2=A0 unicode-post-font-backend
=C2=A0 =C2=A0 unicode-pre-font-backend
=C2=A0 =C2=A0 v1_7i
=C2=A0 =C2=A0 v2007-Sep-10
=C2=A0 =C2=A0 xwidget-0.2

* Change lisp/version.el and Makefile.in so build is fully working
=C2=A0 from a git repo. See the it version of a version getter at
=C2=A0 http://lists.gnu.org/archive/html/emacs-devel= /2013-10/msg00430.html

* Lift bzr references in the git repo. =C2=A0Substeps:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Commits to bzr and git repos are temporarily= closed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2. I clone the Savannah git repo.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3. I signal for a reset of the Savannah git rep= o to empty.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 4. I apply a pre-built reposurgeon script fixin= g the references.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 5. I push the altered repo to the empty repo on= Savannah.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 6. Commits are opened again. =C2=A0(The commit-= mirroring from bzr
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will not care that the git repo ha= s been altered.)

* Add language to the hacking guides about using VCS-independent
=C2=A0 action stamps or references by content, rather than git hashes,
=C2=A0 in commit comments.

* Create an Emacs GPG identity and use it to cryptosign release tags.
=C2=A0 (Reference lifting must happen first.) The following release tags, a= t
=C2=A0 minimum, should be replaced with cryptosigned annotated tags.

=C2=A0 =C2=A0 emacs-19.34
=C2=A0 =C2=A0 emacs-20.1
=C2=A0 =C2=A0 emacs-20.2
=C2=A0 =C2=A0 emacs-20.3
=C2=A0 =C2=A0 emacs-20.4
=C2=A0 =C2=A0 emacs-21.1
=C2=A0 =C2=A0 emacs-21.2
=C2=A0 =C2=A0 emacs-21.3
=C2=A0 =C2=A0 emacs-22.1
=C2=A0 =C2=A0 emacs-22.2
=C2=A0 =C2=A0 emacs-22.3
=C2=A0 =C2=A0 emacs-23.1
=C2=A0 =C2=A0 emacs-23.2
=C2=A0 =C2=A0 emacs-23.3
=C2=A0 =C2=A0 emacs-23.4
=C2=A0 =C2=A0 emacs-24.1
=C2=A0 =C2=A0 emacs-24.2
=C2=A0 =C2=A0 emacs-24.3

* Add a recipe for cryptosigning to the Emacs release procedure.

* Better cross-VCS integration of smerge in vc.el. =C2=A0Here are Stefan= 9;s
=C2=A0 requirements:

=C2=A0- Improve vc-git.el so that it can automatically enable smerge-mode w= hen
=C2=A0 =C2=A0opening a conflicted file and (probably conditional on a confi= g var)
=C2=A0 =C2=A0mark the file as "not conflicted any more" when savi= ng with no
=C2=A0 =C2=A0remaining diff3 markers.
=C2=A0 =C2=A0This currently works in vc-bzr.el (and vc-svn.el as well, IIRC= ).

=C2=A0- Improve vc-git.el with vc-git-conflicted-files so that
=C2=A0 =C2=A0vc-find-conflicted-files works for Git as well.

* Work with hydra-users mailing list to update hydra build config.

* Christopher Schmidt <c_sch= m80@uni-muenster.de> said:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Please examine this list of tag names, I w= ant to know which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > should be thrown out to reduce clutter.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > v0.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > v0.1.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > v0.1.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > v0.1.2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > v0.1.3

=C2=A0 =C2=A0 =C2=A0 =C2=A0 What objects does these tags point to? =C2=A0Th= ese might be some
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leftovers of a failed merge of a package of min= e from my git
=C2=A0 =C2=A0 =C2=A0 =C2=A0 repo to the (back then) bzr elpa branch of the = repository. =C2=A0If
=C2=A0 =C2=A0 =C2=A0 =C2=A0 so, please drop them.

=C2=A0 =C2=A0Must follow through on this.

* Eli Zaretskii writes:

=C2=A0 =C2=A0 =C2=A0> Which reminds me: what about the "fixes bug&q= uot; field of the commit
=C2=A0 =C2=A0 =C2=A0> metadata? are they copied into the git repo? =C2= =A0If so, how can I display
=C2=A0 =C2=A0 =C2=A0> them in git?

* Eli Zaretskii has some to-dos about the Emacs wiki:

=C2=A0 =C2=A0 . The section about merging to the upstream master seems to o= mit "git
=C2=A0 =C2=A0 =C2=A0 =C2=A0push" after merging the task onto the maste= r branch. =C2=A0It ends with
=C2=A0 =C2=A0 =C2=A0 =C2=A0the "git commit" command, which AFAIK = is not the end of the story.

=C2=A0 =C2=A0 =C2=A0. The few places that describe a merge from another bra= nch seem to
=C2=A0 =C2=A0 =C2=A0 =C2=A0say that one needs to issue 2 commands: "gi= t merge" and "git commit".
=C2=A0 =C2=A0 =C2=A0 =C2=A0Perhaps I'm confused, but isn't it true = that "git merge"
=C2=A0 =C2=A0 =C2=A0 =C2=A0automatically commits if there are no conflicts?= =C2=A0If I'm right, an
=C2=A0 =C2=A0 =C2=A0 =C2=A0explicit commit is needed after merge only when = there are conflicts
=C2=A0 =C2=A0 =C2=A0 =C2=A0to be resolved.

=C2=A0 =C2=A0 =C2=A0 =C2=A0For the same reason, is "git revert" T= RT when a push upstream fails
=C2=A0 =C2=A0 =C2=A0 =C2=A0after a merge from the local task branch, becaus= e someone else
=C2=A0 =C2=A0 =C2=A0 =C2=A0pushed meanwhile? =C2=A0The merge is already com= mitted locally, so what
=C2=A0 =C2=A0 =C2=A0 =C2=A0will revert do? =C2=A0I think one will need &quo= t;git reset" in this case.

=C2=A0 =C2=A0 =C2=A0. I would suggest describing the setup of git-merge-cha= ngelog,
=C2=A0 =C2=A0 =C2=A0 =C2=A0because as long as we keep ChangeLog files in th= e repository,
=C2=A0 =C2=A0 =C2=A0 =C2=A0people might bump into conflicts in the logs, an= d it would be nice
=C2=A0 =C2=A0 =C2=A0 =C2=A0to avoid that.

=C2=A0 =C2=A0 =C2=A0. I think we should discuss some more how to work with = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0development trunk and the release branch in para= llel, and reflect
=C2=A0 =C2=A0 =C2=A0 =C2=A0the results of the discussion in the Wiki.

=C2=A0 =C2=A0 =C2=A0 =C2=A0The issue here is that the release branch and th= e trunk diverge
=C2=A0 =C2=A0 =C2=A0 =C2=A0very quickly after the branch point, and the res= ult is that after
=C2=A0 =C2=A0 =C2=A0 =C2=A0you checkout the other branch, you generally nee= d a very long
=C2=A0 =C2=A0 =C2=A0 =C2=A0build, many times a full bootstrap. =C2=A0While = on a modern system, a
=C2=A0 =C2=A0 =C2=A0 =C2=A0full bootstrap should take a few minutes, it is = still annoyingly
=C2=A0 =C2=A0 =C2=A0 =C2=A0long, and makes higher the risk of losing the ra= ce against other
=C2=A0 =C2=A0 =C2=A0 =C2=A0committers. =C2=A0In addition, you only have a s= ingle executable at any
=C2=A0 =C2=A0 =C2=A0 =C2=A0given time, so comparison of behavior between th= e two branches is
=C2=A0 =C2=A0 =C2=A0 =C2=A0difficult.

=C2=A0 =C2=A0 =C2=A0 =C2=A0So perhaps we should find a way of having two se= parate branches,
=C2=A0 =C2=A0 =C2=A0 =C2=A0such that switching between them does not requir= e a build if
=C2=A0 =C2=A0 =C2=A0 =C2=A0nothing changed.

=C2=A0 =C2=A0Some of these are easy tasks. =C2=A0Some of them are research = papers.

Git transition:

1. Wait on 24.4 release and Stefan's go signal.

2. Andreas announces on the dev list that the changeover is beginning.
b
3. Andreas turns off bzr commit mirroring (and disables the bzr repo).

4. Andreas enters a small documentation commit recording the changeover.
5. Andreas installs a commit hook that mails notifications to the emacs-dif= fs
=C2=A0 =C2=A0mailing list. (This could be done sooner without disruption.)<= br>
6. Andreas repacks the repo. (This could be done sooner without disruption.= )

7. Andreas announces on the dev list that the git repo is live for
=C2=A0 =C2=A0developer pushes.

8. Someone updates http://savannah.gnu.org/projects/emacs/ to reflect the ch= ange

9. I mark the wiki pages on Bzr obsolete and update the Git ones.

10. I will do the work required to update root and /admin to reflect
=C2=A0 =C2=A0 git use over the following few days. (/etc is clean already.)= In
=C2=A0 =C2=A0 root, Makefile.in refers to a bzr file and that's it.

/etc cleanup:

1. Remove /etc/JOKES (but save the EMACS acronyms)

2. Compile a list of suggested dispositions for every file in /etc (keep, =C2=A0 =C2=A0delete, move to new directory)

3. Implement 2 after list review.

Asynchronously:

1. VC has these known bugs:

http://debbugs.gn= u.org/8288
http://debbugs.gn= u.org/8756
http://debbugs.g= nu.org/15696
http://debbugs.g= nu.org/10378
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"= http://www.catb.org= /~esr/">Eric S. Raymond</a>

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- "M.T. Cicero", in a newspaper lett= er of 1788 touching the "militia"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 referred to in the Second Amendme= nt to the Constitution.


--001a11364106e842e404efb56acd--