Hi, On Sat, Jun 30, 2018 at 07:04:01AM +0100, Sean Whitton wrote: > Hello, > > Great to see progress on this. Thanks. David's bug triaging has been invaluable. > On Fri, Jun 29 2018, Nicholas D Steeves wrote: > > > Sean, so I guess we're in phase 2 (breaking out those two pkgs was > > phase 1). I'll definitely be returning to reread your comments when > > we hit phase 3—considering becoming upstream for a subset of packages. > > Thank you :-) > > Well, we've already made ourselves upstream of dpkg-dev-el and > debian-el... I'm hoping maintainance of most loved addons is distributed between multiple people... > > To Team: At this point the plan seems to be to outright drop anything > > with a dead upstream. > > > > 11. At what point in the future do you think packages should be > > removed from goodies when a maintainer for the elpa-variant hasn't > > yet stepped forward? eg: Let's define this best case scenario: > > all 90 subpackages have been triaged before DebCamp. Worst case > > of: sometime before September. > > > > Aug 12th is six months before the "no-rentry into testing" > > deadline of Feb 2019. > > Well, it's a matter of whether or not we think they should be in buster. > > It seems unlikely that these packages lost their active maintainership > since stretch was released, so they've already been in one stable > release in their current state. So it seems reasonable not to include > them in buster? Might not want to cut it too close to the freeze in > case there are delays. Ah, I should have clarified that the ones that are being targeted for removal are ones with old bugs with no resolution in sight, and definitely cases where the upstream author says a project is unmaintained because equivalent functionality is now built-in to GNU Emacs. I'm going to try for an optimistic removal goal of July 12th, because that will give potential maintainers of the removed addons time to realise "oh, this is missing now and I care enough about it to maintain it". Maybe that's overly aggressive, but there are still something like 70/90 packages left to elpafy or drop. Then there are cases like color-theme vs native deftheme/custom themes. > > To Team: Ok, with the work in progress src:emacs-goodies-el is > > dropping XEmacs support, and this is documented in debian/NEWS. > > Good idea to add debian/NEWS. Also, the faster moving details and stuff like x was dropped, use built-in y instead are tracked in README.Debian. Where z provides the functionality of x, x was dropped from goodies, but z was never in emacs-goodies-el, do you think a suggests or recommends would be more appropriate? Eventually the elpafied packages will be Depends for the dummy package, but if one is taking the time to find a suitable replacement and justify x's removal, then it seems like we might as well profit from the time investment while making the user's life a bit easier by adding a suggests/recommends. My gut feeling is a suggests would be most appropriate, even though a recommends would be more convenient to the user. Cheers, Nicholas
Attachment:
signature.asc
Description: PGP signature