Hi Julian and Emacsen Team,
Thank you very much for taking the time to reply to these questions.
You can skip the rest of this email if you're busy, and there will be
no more CCed emails :-)
Breaking up emacs-goodies-el and working to make it a transitional
package is now underway. David, I'm very grateful for your bug
triaging. It makes sense to cut down on the number of packages before
considering the possibility of maintaining any. Also, thanks for
doing dpkg-dev-el and debian-el.
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 :-)
On Mon, Jun 25, 2018 at 10:48:41PM +0100, Julian Gilbey wrote:
> On Thu, Jun 14, 2018 at 03:25:14PM -0400, Nicholas D Steeves wrote:
> >
> > 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).
Thanks for confirming, I won't add either of you.
> > 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.
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.
> > 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.
To Team: Ok, with the work in progress src:emacs-goodies-el is
dropping XEmacs support, and this is documented in debian/NEWS.
Cheers,
Nicholas
Attachment:
signature.asc
Description: PGP signature