unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* ESR's intimidatingly huge task list
@ 2014-01-11 16:56 Eric S. Raymond
  2014-01-11 17:46 ` Bozhidar Batsov
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Eric S. Raymond @ 2014-01-11 16:56 UTC (permalink / raw)
  To: emacs-devel

*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 <c_schm80@uni-muenster.de> 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="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.



^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-01-24  8:56 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-11 16:56 ESR's intimidatingly huge task list Eric S. Raymond
2014-01-11 17:46 ` Bozhidar Batsov
2014-01-11 18:10   ` Rüdiger Sonderfeld
2014-01-11 18:26     ` Andreas Schwab
2014-01-23 18:47       ` Rüdiger Sonderfeld
2014-01-23 19:22         ` Eric S. Raymond
2014-01-24  8:56           ` Bozhidar Batsov
2014-01-23 19:25         ` Andreas Schwab
2014-01-11 18:07 ` Rüdiger Sonderfeld
2014-01-11 20:50   ` Eric S. Raymond
2014-01-15 17:31 ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).