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
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Dear Mark, For the context of this bug please consult: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899221 Thank you for maintaining XEmacs. A couple of professors during my undergrad were die-hard fans, and whenever I convert a package to dh-elpa I worry if it will be disruptive to one of them or if they've all since switched to GNU Emacs. As part of investigating issues related to the (increasingly near) future elpafication of src:emacs-goodies-el, I've discovered the package seems to contain some libraries that IIRC are now be builtin to GNU Emacs (eg: color-theme-library.el). Because the resulting dh-elpa-created packages will be incompatible with XEmacs, it occurred to me that you might want to insure convenient access to the libraries your users are accustomed to. The easiest course of action seems like it would be to provide NEWS at the time of emacs-goodies-el upgrade, to warn XEmacs users of the change... It might also be nice to provide an XEmacs package that contains the emacs-goodies-el libraries that are now part of GNU Emacs, but that's very much an "extra work" thing. Are you interested in it? At any rate, this email has grown too long. I just wanted to reach out and let you know I'm not trying to subvert the established XEmacs userbase and request comment on an issue that will soon emerge. Sincerely, Nicholas signature.asc Description: PGP signature
Bug#901157: Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Hello Peter, On Sun, Jun 17 2018, Peter S Galbraith wrote: > I thinks it's clear that I don't have enough time for most of my > Debian packages and should trim the list to the bare minimum. > > I would be happy to have one or both of you take over the package. > Julian feels the same way. Thanks. We will bring the package under team maintainership and stop CCing you on everything :) Do let us know if you want to be involved at a later date. -- Sean Whitton signature.asc Description: PGP signature
Bug#901157: Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Hi everyone, I thinks it's clear that I don't have enough time for most of my Debian packages and should trim the list to the bare minimum. I would be happy to have one or both of you take over the package. Julian feels the same way. Thanks, Peter
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Hello Nicholas, The things you've suggested in this most recent e-mail all involve massive changes to emacs-goodies-el, which I don't think can be done without the involvement of its maintainers. It's just too much for an NMU. Creating new source packages with elpafied versions of addons, and then asking for those to be deleted from emacs-goodies-el, does not have this problem. -- Sean Whitton signature.asc Description: PGP signature
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Hello to everyone reading this, Thank you very much for replying! On Thu, Jun 14, 2018 at 05:16:07PM -0300, David Bremner wrote: > Nicholas D Steeves writes: > > > > > 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? > > Well, it's a team goal, but the packages are not team packages. So it > would be nice to have some feedback from Julian or Peter here. There > has been no such announcement; I guess it would be up to either Rob as > maintainer of emacsen-common, or the xemacs maintainer. Reply a couple of lines below. On Fri, Jun 15, 2018 at 12:00:42PM +0100, Sean Whitton wrote: > > This is not up to any of us, but the Debian maintainer of xemacs. And I > do not believe he has any intention of dropping support. 10. Hm, what about the following: Each bin:$package currently in src:emacs-goodies-el becomes bin:xemacs-$package, that provides the virtual package $package. Then, to fix the unversioned Emacs bug in debian-el and dpkg-el, we fork src:emacs-goodies-el into multiple src:packages. eg: as David and I have already done. It would be nice if emacs-goodies-el provided a tarball or tag without packaging, or alternative a patches-applied git remote with a custom merge driver could be used to merge everything except emacs-goodies-el/debian. Src:various-goodies-fork/debian/control would provide the appropriate bin:elpa-various-goodies-fork; however, the source package for each of src:various-goodies-fork would unfortunately contain all of the src:emacs-goodies-el source at this time. The extraneous content can be pruned (or just git removed if preferred) at a later date as src:emacs-goodies-el is broken up (if it is broken up). Most importantly, the each bin:elpa-various-goodies-fork provides its respective virtual package. Eg, bin:elpa-debian provides bin:debian-el, which is also provided by bin:xemacs-debian-el. The one thing I'm not sure about is how to handle the upgrade path... Is there a way to prefer elpa-debian over xemacs-debian-el when both xemacs and emacs are installed? Skip to the bottom for info on the dummy transition package. > > 0. Is the Emacsen Team going to maintain all of the new packages? > > Yes, but don't forget the Policy requirement that at least one human be > listed in Uploaders. > > > If so, can Peter S Galbraith and Julian Gilbey be added to the team > > and to the Uploaders for all these new packages? > > Only if they explicitly consent to their addition to each individual > package. Alternatively, isn't it possible to add the elpa-variants to src:emacs-goodies-el? Would that be preferred at this time, and gradually break out the elpafied packages into their own src:elpafied-packages as human Uploaders volunteer? > > 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? > > On both of these issues, we've all already given you our opinions in > previous messages and/or IRC. Since you're doing the work, you get to > decide between those opinions. > > > 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? > > Seems like an oversight. A transitional package would be useful to > users. To add to [10], xemacs-goodies-el should provide the virtual emacs-goodies-el, and elpa-goodies can also do the same? In this case elpa-goodies would be a dummy transitional package. Maybe this is an ugly and cumbersome approach, but it seems like it would be less disruptive to xemacs users and less hijacky to src:emacs-goodies-el. What does everything think? Nicholas signature.asc Description: PGP signature
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Hello, On Thu, Jun 14 2018, Nicholas D Steeves wrote: > 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? This is not up to any of us, but the Debian maintainer of xemacs. And I do not believe he has any intention of dropping support. > 0. Is the Emacsen Team going to maintain all of the new packages? Yes, but don't forget the Policy requirement that at least one human be listed in Uploaders. > If so, can Peter S Galbraith and Julian Gilbey be added to the team > and to the Uploaders for all these new packages? Only if they explicitly consent to their addition to each individual package. > 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? > 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? On both of these issues, we've all already given you our opinions in previous messages and/or IRC. Since you're doing the work, you get to decide between those opinions. > 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? Seems like an oversight. A transitional package would be useful to users. -- Sean Whitton
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Nicholas D Steeves writes: > 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: >> >> 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? Well, it's a team goal, but the packages are not team packages. So it would be nice to have some feedback from Julian or Peter here. There has been no such announcement; I guess it would be up to either Rob as maintainer of emacsen-common, or the xemacs maintainer. d
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
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 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
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Sean Whitton 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. d
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
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. > I guess we could ask the perl people what there experience of > releasing Debian-ish things on CPAN is. Well, one data point is that they switched dh-make-perl non-native->native and stopped publishing it on CPAN a few years. ago. -- Sean Whitton
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Sean Whitton writes: > There seem to be two schools of thought here: > > - native packages are to be used when the package's release process is > uploading to Debian unstable Well, that's reasonably convincing, despite being unsupported by policy ;). >> I don't propose to have seperate upstream repos, only branches. > > Even if Nick goes with non-native I think this is overkill. You can > just use a single branch containing both 1.2.3 and debian/1.2.3-1 > release tags. Downstreams can just ignore the debian/ dir. See > https://git.spwhitton.name/git-remote-gcrypt for an example of this. 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. I guess we could ask the perl people what there experience of releasing Debian-ish things on CPAN is. d
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Hello David, On Sat, Jun 09 2018, David Bremner wrote: >> I think they should probably be native packages. > > Perhaps. There is this: > > https://apps.fedoraproject.org/packages/emacs-goodies > https://bugzilla.redhat.com/show_bug.cgi?id=1063750 > > If other (non-downstream) distros are going to have them, it's maybe > better to have a real upstream to centralize bug reporting. I don't see why the Debian BTS couldn't be used for that. > In any case, they need an "elpa name" to e.g. go in the define-package > form and the binary package name. > > What are the advantages of being native packages? There seem to be two schools of thought here: - native packages are to be used when the package's release process is uploading to Debian unstable - native packages are to be used when the package was written especially for Debian Despite the fact that Policy says the latter, I'm inclined towards the former, so the advantage from my point of view is semantic correctness :) > I don't propose to have seperate upstream repos, only branches. Even if Nick goes with non-native I think this is overkill. You can just use a single branch containing both 1.2.3 and debian/1.2.3-1 release tags. Downstreams can just ignore the debian/ dir. See https://git.spwhitton.name/git-remote-gcrypt for an example of this. -- Sean Whitton
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Sean Whitton writes: >> David Bremner wrote >> >> I (so-far) had the idea that "dpkg-dev", and "debian" could be >> upstream packages in e.g. melpa-stable. OTOH, "debian" is annoyingly >> generic, so that might have to change. > > If they are native packages, they should not be published to MELPA. > > I think they should probably be native packages. Perhaps. There is this: https://apps.fedoraproject.org/packages/emacs-goodies https://bugzilla.redhat.com/show_bug.cgi?id=1063750 If other (non-downstream) distros are going to have them, it's maybe better to have a real upstream to centralize bug reporting. In any case, they need an "elpa name" to e.g. go in the define-package form and the binary package name. What are the advantages of being native packages? I don't propose to have seperate upstream repos, only branches. d
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Hello, On Sat, Jun 09 2018, David Bremner wrote: > Nicholas D Steeves writes: > >> P.P.S. I can start with one of debian-el, devscripts-el, or >> dpkg-dev-el as a proof of concept, and it will also be easier to just >> iterate over the *.els once these exceptions have been dealt with. I >> assume that they ought to remain grouped together and become >> elpa-debian-el, elpa-devscripts.el, and elpa-dpkg-dev.el, with >> repositories on salsa named debian-el, devscripts-el, and >> dpkg-dev-el. > > I've actually done this, before finding this message. > > See > > https://salsa.debian.org/emacsen-team/dpkg-dev-el > https://salsa.debian.org/emacsen-team/debian-el > > The former depends on the latter, as it turns out. > > FWIW, I don't think any binary package ought to start with "elpa" and > end "-el" or "\.el", but other than that I'm flexible about the > naming. > > I (so-far) had the idea that "dpkg-dev", and "debian" could be > upstream packages in e.g. melpa-stable. OTOH, "debian" is annoyingly > generic, so that might have to change. If they are native packages, they should not be published to MELPA. I think they should probably be native packages. -- Sean Whitton
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Nicholas D Steeves writes: > P.P.S. I can start with one of debian-el, devscripts-el, or > dpkg-dev-el as a proof of concept, and it will also be easier to just > iterate over the *.els once these exceptions have been dealt with. I > assume that they ought to remain grouped together and become > elpa-debian-el, elpa-devscripts.el, and elpa-dpkg-dev.el, with > repositories on salsa named debian-el, devscripts-el, and dpkg-dev-el. I've actually done this, before finding this message. See https://salsa.debian.org/emacsen-team/dpkg-dev-el https://salsa.debian.org/emacsen-team/debian-el The former depends on the latter, as it turns out. FWIW, I don't think any binary package ought to start with "elpa" and end "-el" or "\.el", but other than that I'm flexible about the naming. I (so-far) had the idea that "dpkg-dev", and "debian" could be upstream packages in e.g. melpa-stable. OTOH, "debian" is annoyingly generic, so that might have to change. d
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
P.P.S. I can start with one of debian-el, devscripts-el, or dpkg-dev-el as a proof of concept, and it will also be easier to just iterate over the *.els once these exceptions have been dealt with. I assume that they ought to remain grouped together and become elpa-debian-el, elpa-devscripts.el, and elpa-dpkg-dev.el, with repositories on salsa named debian-el, devscripts-el, and dpkg-dev-el. signature.asc Description: PGP signature
Bug#899221: [medium size project] break up emacs-goodies-el into many elpafied packages
Package: emacs-goodies-el Version: 36.3+nmu1 Severity: normal Dear Peter, Thank you for maintaining emacs-goodies-el; It has proven to be invaluable for a variety of tasks. Sean Whitton and I have recently been discussing the challenge of breaking up emacs-goodies.el into many elpafied packages. I am filing this bug so there will be a site to coordinates efforts to this end. Is it something you're already working on, or something you wouldn't object to having the Debian Emacsen team help out with? How important is git history to you? While it is possible to script pruning and rewriting history for each new repository (consisting of the .el, documentation, patches, changelog, and copyright) this will be a lot of work! I'd also like to break up the process into a series of steps, so that other people can resume progress if the effort stalls, and possibly also break it up into no more than four sections (count of *.els / 4), so that the labour of any manual steps can be divided between multiple people. Finally, if there are any bugs in the script, doing it in multiple steps will provide checkpoints and a way to gauge progress. Please feel free to define this sequence, or ping me if I haven't submitted one by the first of June. Kind regards, Nicholas P.S. Do you know a way to automate the triaging of ~100 bugs against goodies, and to reassign them to their respective (future) elpafied packages?
