|
| From: | Bozhidar Batsov |
| Subject: | Re: ESR's intimidatingly huge task list |
| Date: | Sat, 11 Jan 2014 19:46:08 +0200 |
*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 <address@hidden> 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
--
<a href="" href="http://www.catb.org/~esr/" target="_blank">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.
-- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia"
referred to in the Second Amendment to the Constitution.
| [Prev in Thread] | Current Thread | [Next in Thread] |