From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: esr@thyrsus.com (Eric S. Raymond) Newsgroups: gmane.emacs.devel Subject: ESR's intimidatingly huge task list Date: Sat, 11 Jan 2014 11:56:35 -0500 (EST) Message-ID: <20140111165635.D683C3803A6@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389459432 13371 80.91.229.3 (11 Jan 2014 16:57:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 16:57:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 11 17:57: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 1W21s4-0008Jx-Ft for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 17:57:16 +0100 Original-Received: from localhost ([::1]:34698 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W21s4-0007UJ-5y for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 11:57:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W21ry-0007UB-CN for emacs-devel@gnu.org; Sat, 11 Jan 2014 11:57:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W21ru-0006gV-Cn for emacs-devel@gnu.org; Sat, 11 Jan 2014 11:57:10 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:52512 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W21ru-0006gQ-7a for emacs-devel@gnu.org; Sat, 11 Jan 2014 11:57:06 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id D683C3803A6; Sat, 11 Jan 2014 11:56:35 -0500 (EST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:168093 Archived-At: *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.