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.
On Sun, Jun 10, 2018 at 12:33:21PM -0300, David Bremner wrote: > Sean Whitton <spwhit...@spwhitton.name> writes: > > > Hello, > > > > On Sun, Jun 10 2018, David Bremner wrote: > > > >> This is pretty much what notmuch does as well (with 1.2.3-2 > >> effectively a point release with selective distribution). The argument > >> gets a bit circular here. Branches make sense if you think separete > >> upstream releases on MELPA make sense. > > > > It might not be crazy to have MELPA (like Fedora) be a downstream of the > > native package in the Debian archive. > > Hmm. Well, it wouldn't be my first choice, but I think it's not really > the most important issue to figure out. For example, are we ready to > drop xemacs support from dpkg-dev-el and debian-el? If not, then that's > a problem. OTOH, I also don't want to block the transition to > unversioned emacs. Or be sucked into the briarpatch of maintaining > emacs-goodies-el. I've also been wondering about Debian's xemacs support for a year, and the position I've formed (which Sean has confirmed) is that as a general case packages should be transitioned to dh-elpa. Given the specific case of unversioned emacs support as a team goal it seems clear that xemacs support should be dropped at this time. Has there yet been an official announcement to users that xemacs is depreciated in Debian? 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? 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? 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. 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? 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? 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. Cheers, Nicholas
signature.asc
Description: PGP signature
