On Thu, Jun 14, 2018 at 03:25:14PM -0400, Nicholas D Steeves wrote: > Hi! > > Sorry for the delay replying to this thread, I've had a busy week and > won't have time to work on dpkg-dev-el and debian-el until Tuesday the > 19th. Reply follows below. Please comment on at least four or five > points.
Hi, Sorry, been busy and have only just got to my emacs-related emails. I'm guessing that Peter may well be even later to this discussion... > Re: briarpatch of src:emacs-goodies-el. > > 0. Is the Emacsen Team going to maintain all of the new packages? If > so, can Peter S Galbraith and Julian Gilbey be added to the team and > to the Uploaders for all these new packages? I have really not had the skill or time to maintain these, unfortunately. For this reason, I don't think it's worth listing me on the elpa-ified packages, and I think Peter said that he was happy for you all to adopt the package (so not to list him either). > 1. Src:emacs-goodies-el is a native 3.0 package, but includes many > quilt packages. I think the historical reason for this is that it > allowed the maintainer to manually update a lisp file from a mailing > list, wiki, or forum copy, and then resolve conflicts between hunks of > the patch and the new upstream source. Also, this preserves > separation between these sources and Debian changes... > > It is clear that any bin:emacs-goodies-el component that has a living > upstream should be transitioned to a non-native elpafied package, but > maybe this would be a good time to take advantage of one of the > conveniences of native-packaging for packages that do no have a living > upstream? eg: We apply the stack of patches to the native package > source. Conversely, if maintaining a pristine copy of the original > source is more desirable then wouldn't a non-native package be more > appropriate? This all sounds sensible to me. > 2. Src:emacs-goodies-el contains a lot of Debian-provided > documentation and facilities for updating that documentation. A lot > of the (difficult to automate) work of resolving this bug will be to > split up that documentation and possibly also forward upstream PRs. Indeed. And if things can be simplified in the process, all the better. > 3. Is the consensus is that the git history of all the new packages > does not need to be preserved from src:emacs-goodies-el? In light of > #1, and moving to a bunch of native packages without quilt patches, I > guess the patches should be applied to src:emacs-goodies-el, then the > patch files deleted, and then these changes should be pushed to the > existing repository, and then this repository should be frozen. This > will allow each of the new src packages to refer to the old git repo > URL. Agreed? I'm fine with that. The current git repo is just a copy of the former CVS repo anyway. But see the next two points. > 4. I noticed that emacs-goodies-el has not had a dependency on an > elpafied packages added each time a file is removed. This seems to > indicate that when this work is completed bin:emacs-goodies-el will > just silently disappear and users will be left without the modes they > are used to having after an upgrade. Is this intended, or should > emacs-goodies-el become a dummy transitional package? emacs-goodies-el should certainly become a dummy transitional package - that is good Debian practice. Then the git repo will also have to be preserved. > 5. It seems like emacs-goodies-el should be kept around as a dummy > package for the purposes of bug tracking, because I don't think anyone > should be rushed to triage src:emacs-goodies-el's many bug reports. See point 4: it still will be. For the bug reports, when the package is elpa-ified, it would be good to at least reassign the bugs to the relevant new package, though that is a fair bit of work. I have nothing to add to the XEmacs discussion. Best wishes, and thanks so much for all of your (plural) work on this package! Julian
