Re: Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
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
Reply to: