ESR's intimidatingly huge task list

ESR's intimidatingly huge task list

[Eric S. Raymond]

*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.

Re: ESR's intimidatingly huge task list

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 9424 bytes --]

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 <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.  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.
>
>

[-- Attachment #2: Type: text/html, Size: 11771 bytes --]

Re: ESR's intimidatingly huge task list

[Rüdiger Sonderfeld]

On Saturday 11 January 2014 19:46:08 Bozhidar Batsov wrote:
> 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.

Is there a reason we can't simply copy .bzrignore to .gitignore?  I was 
wondering about that when I recently updated .gitignore a bit.  The format 
seems to be the same.

Regards,
Rüdiger

Re: ESR's intimidatingly huge task list

[Andreas Schwab]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> Is there a reason we can't simply copy .bzrignore to .gitignore?  I was 
> wondering about that when I recently updated .gitignore a bit.  The format 
> seems to be the same.

They are not identical, for example leading ./ in bzrignore maps to
leading / in gitignore.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ESR's intimidatingly huge task list

[Rüdiger Sonderfeld]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

On Saturday 11 January 2014 19:26:19 Andreas Schwab wrote:
> Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:
> > Is there a reason we can't simply copy .bzrignore to .gitignore?  I was
> > wondering about that when I recently updated .gitignore a bit.  The format
> > seems to be the same.
> 
> They are not identical, for example leading ./ in bzrignore maps to
> leading / in gitignore.

Are there any other major differences besides this?  I've replaced the ./ with 
/ in bzrignore and use it with git now.  If this looks good I'll commit it to 
trunk.

Regards,
Rüdiger

[-- Attachment #2: .gitignore --]
[-- Type: text/plain, Size: 4403 bytes --]

*~
/_dir-locals.el
/bin
/BIN
/config.cache
/config.log
/config.status
/data
/etc/icons
/etc/__pycache__
/libexec
/lock
/README.W32
/share
/site-lisp
/var
oo
oo-spd
*.dSYM
*.elc
*.exe
*.res
*.tmp
src/temacs.map
/aclocal.m4
autom4te.cache
confdefs.h
/configure
configure.lineno
conftest*
core
DOC
# make-dist output.
/emacs-*
GPATH
GRTAGS
GTAGS
ID
makefile
Makefile
/GNUmakefile.unix
stamp-h1
stamp_BLD
subdirs.el
TAGS
cxxdefs.h
!admin/charsets/Makefile
# Intermediate files when making pdf versions of the manuals.
doc/**/*.aux
doc/**/*.cm
doc/**/*.cms
doc/**/*.cp
doc/**/*.cps
doc/**/*.fn
doc/**/*.fns
doc/**/*.ky
doc/**/*.kys
doc/**/*.log
doc/**/*.op
doc/**/*.ops
doc/**/*.pg
doc/**/*.pgs
doc/**/*.pj
doc/**/*.pjs
doc/**/*.sc
doc/**/*.scs
doc/**/*.ss
doc/**/*.tg
doc/**/*.tgs
doc/**/*.toc
doc/**/*.tp
doc/**/*.tps
doc/**/*.vr
doc/**/*.vrs
doc/**/*.dvi
doc/**/*.html
doc/**/*.pdf
doc/**/*.ps
!doc/lispintro/cons-*.pdf
!doc/lispintro/drawers.pdf
!doc/lispintro/lambda-*.pdf
etc/emacs.tmpdesktop
!etc/refcards/Makefile
etc/refcards/*.aux
etc/refcards/*.log
# FIXME this ignores info and everything in it.
# It would be better to only ignore:
# info/ (i.e., just the directory) and info/*.info.
info/
admin/unidata/unidata.txt
build-aux/compile
build-aux/config.guess
build-aux/config.sub
build-aux/depcomp
build-aux/install-sh
build-aux/missing
leim/changed.misc
leim/changed.tit
lib/.deps
lib/Makefile.in
lib/deps
lib/alloca.h
lib/arg-nonnull.h
lib/byteswap.h
lib/c++defs.h
lib/dirent.h
lib/errno.h
lib/execinfo.h
lib/fcntl.h
lib/getopt.h
lib/inttypes.h
lib/stdalign.h
lib/stdbool.h
lib/stdio.h
lib/stdint.h
lib/stdlib.h
lib/string.h
lib/sys
lib/SYS
lib/time.h
lib/unistd.h
lib/warn-on-use.h
lib/alloca.in-h
lib/getopt.in-h
lib/signal.in-h
lib/signal.h
lib/stdbool.in-h
lib/stddef.in-h
lib/stdint.in-h
lib/stdio.in-h
lib/stdlib.in-h
lib/sys_stat.in-h
lib/time.in-h
lib/unistd.in-h
lib/cxxdefs.h
lib-src/blessmail
lib-src/ctags
lib-src/ctags.c
lib-src/ebrowse
lib-src/emacsclient
lib-src/etags
lib-src/fakemail
lib-src/hexl
lib-src/make-docfile
lib-src/movemail
lib-src/profile
lib-src/test-distrib
lib-src/update-game-score
lisp/**/*-loaddefs.el
lisp/**/loaddefs.el
lisp/cus-load.el
## Generated grammar files.
lisp/cedet/semantic/bovine/c-by.el
lisp/cedet/semantic/bovine/make-by.el
lisp/cedet/semantic/bovine/scm-by.el
lisp/cedet/semantic/wisent/javat-wy.el
lisp/cedet/semantic/wisent/js-wy.el
lisp/cedet/semantic/wisent/python-wy.el
lisp/cedet/srecode/srt-wy.el
lisp/eshell/esh-groups.el
lisp/finder-inf.el
lisp/gnus/_dir-locals.el
# Generated Unicode files.
lisp/international/charprop.el
lisp/international/uni-bidi.el
lisp/international/uni-category.el
lisp/international/uni-combining.el
lisp/international/uni-comment.el
lisp/international/uni-decimal.el
lisp/international/uni-decomposition.el
lisp/international/uni-digit.el
lisp/international/uni-lowercase.el
lisp/international/uni-mirrored.el
lisp/international/uni-name.el
lisp/international/uni-numeric.el
lisp/international/uni-old-name.el
lisp/international/uni-titlecase.el
lisp/international/uni-uppercase.el
lisp/leim/ja-dic
lisp/leim/leim-list.el
# Generated quail files.
lisp/leim/quail/4Corner.el
lisp/leim/quail/ARRAY30.el
lisp/leim/quail/CCDOSPY.el
lisp/leim/quail/CTLau-b5.el
lisp/leim/quail/CTLau.el
lisp/leim/quail/ECDICT.el
lisp/leim/quail/ETZY.el
lisp/leim/quail/PY-b5.el
lisp/leim/quail/PY.el
lisp/leim/quail/Punct-b5.el
lisp/leim/quail/Punct.el
lisp/leim/quail/QJ-b5.el
lisp/leim/quail/QJ.el
lisp/leim/quail/SW.el
lisp/leim/quail/TONEPY.el
lisp/leim/quail/ZIRANMA.el
lisp/leim/quail/ZOZY.el
lisp/leim/quail/quick-b5.el
lisp/leim/quail/quick-cns.el
lisp/leim/quail/tsang-b5.el
lisp/leim/quail/tsang-cns.el
nextstep/Emacs.app
nextstep/Cocoa/Emacs.base/Contents/Info.plist
nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj
nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop
nextstep/GNUstep/Emacs.base/Resources/Info-gnustep.plist
nt/config.log
src/_dbxinit
src/_gdbinit
src/bootstrap-emacs
src/buildobj.h
src/config.h
src/config.in
src/deps
src/emacs
src/emacs-*
src/epaths.h
src/gdb.ini
src/prefix-args*
src/stamp-h.in
src/temacs
test/indent/*.new
!test/automated/flymake/warnpred/Makefile
!test/indent/Makefile
+*
src/globals.h
src/gl-stamp
lisp/mh-e/mh-autoloads.el
lisp/mh-e/mh-cus-load.el
lib/stdalign.h
admin/charsets/*.map
admin/charsets/cp51932.el
admin/charsets/eucjp-ms.el
admin/charsets/jisx2131-filter

Re: ESR's intimidatingly huge task list

[Eric S. Raymond]

Rüdiger Sonderfeld <ruediger@c-plusplus.de>:
> > They are not identical, for example leading ./ in bzrignore maps to
> > leading / in gitignore.
> 
> Are there any other major differences besides this?

None that are used in the Emacs tree.  I researched this when working
on reposurgeon's bzr support; the only other problem appears to be bzr
"RE:" expressions.

> I've replaced the ./ with / in bzrignore and use it with git now.
> If this looks good I'll commit it to trunk.

It might simplify things on conversion day if you don't.

The goal of the final polished conversion is to make it look as though
git had been in use all along - that way people won't see distracting
changes in behavior when they check out old revisions.

This means I'm going to have to write some reposurgeon procedure or facility to
map .bzrignores to .gitignores throughout the history.  Having a .gitignore
already in the tree at final conversion time might complicate that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: ESR's intimidatingly huge task list

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On 23 January 2014 21:22, Eric S. Raymond <esr@thyrsus.com> wrote:

> Rüdiger Sonderfeld <ruediger@c-plusplus.de>:
> > > They are not identical, for example leading ./ in bzrignore maps to
> > > leading / in gitignore.
> >
> > Are there any other major differences besides this?
>
> None that are used in the Emacs tree.  I researched this when working
> on reposurgeon's bzr support; the only other problem appears to be bzr
> "RE:" expressions.
>
> > I've replaced the ./ with / in bzrignore and use it with git now.
> > If this looks good I'll commit it to trunk.
>
> It might simplify things on conversion day if you don't.
>
> The goal of the final polished conversion is to make it look as though
> git had been in use all along - that way people won't see distracting
> changes in behavior when they check out old revisions.
>
> This means I'm going to have to write some reposurgeon procedure or
> facility to
> map .bzrignores to .gitignores throughout the history.  Having a .gitignore
> already in the tree at final conversion time might complicate that.
>

We already have some .gitignore files lying around so this ship has sailed.
I think it makes sense to merge the proposed changes and remove the
.gitignore files in the subdirectories.
Even now people are using the bzr repo via git-brz and they'd benefit from
a proper .gitignore file.



> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>

[-- Attachment #2: Type: text/html, Size: 2270 bytes --]

Re: ESR's intimidatingly huge task list

[Andreas Schwab]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> Are there any other major differences besides this?  I've replaced the ./ with 
> / in bzrignore and use it with git now.  If this looks good I'll commit it to 
> trunk.

You probably want to remove the subdirectory .gitignore files.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ESR's intimidatingly huge task list

[Rüdiger Sonderfeld]

On Saturday 11 January 2014 11:56:35 Eric S. Raymond wrote:
> * 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.

See my patch proposal:
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01038.html

Regards,
Rüdiger

Re: ESR's intimidatingly huge task list

[Eric S. Raymond]

Rüdiger Sonderfeld <ruediger@c-plusplus.de>:
> On Saturday 11 January 2014 11:56:35 Eric S. Raymond wrote:
> > * 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.
> 
> See my patch proposal:
> https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01038.html
> 
> Regards,
> Rüdiger

Thanks, that will help.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: ESR's intimidatingly huge task list

[Eli Zaretskii]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Sat, 11 Jan 2014 11:56:35 -0500 (EST)
> 
> * Eli Zaretskii has some to-dos about the Emacs wiki:

One more comment about the Wiki page: The procedures and the workflow
it recommends don't have to be bug-for-bug compatible with the bzr
equivalents.  That's because the bzr stuff was to some degree
influenced by bzr's weaknesses and misfeatures.  For example, IIRC the
original page suggested to make the trunk mirror branch treeless, but
then we changed that because something, I don't remember what exactly,
didn't work in such branches.

So if git offers better methods, there's no reason to blindly stick to
what we've been doing with bzr, provided that the important traits are
preserved.