Action items

  • we will drop flavours of GNU Emacs, having a single 'emacs' binary package that installs the latest upstream release

    • note that this renders the recent dh_elpa feature request (#869509) invalid/obsolete

    • try to make it easier to downgrade and pin to the version of Emacs in stable; one advantage of multiple flavours that we will lose is easy downgrades if a new upstream release breaks your config/addons

  • we will retain the infrastructure for flavours for now, in case we need it for guilemacs, and so that xemacs21 requires only minimal changes

  • Debian Emacsen policy should recommend using dh-elpa

Switching to a single flavour of GNU Emacs

  1. copy src:emacs25 to new source package src:emacs
  2. give src:emacs an epoch version number: 1:25.2-1
  3. edits to code to handle clash with /usr/share/emacs from upstream? + other paths stuff + policy
  4. move bin:emacs from src:emacs-defaults to new src:emacs
  5. this new bin:emacs will take over from the bin:emacs produced by src:emacs-defaults
  6. after new src:emacs has cleared NEW, RM src:emacs-defaults
  7. dh-elpa maintscripts update & rebuild every dh-elpa package (use dh-elpa-Version field to do this; was added in dh-elpa 1.10, but reverted until a debhelper bug gets fixed)
  8. RC bugs against non-dh-elpa packages, suggesting switching to dh-elpa [on what grounds would these be RC?]

IRC log of meeting

All participants were happy for this to be posted.

Log timezone is MST.

12:04:28-!- dogsleg [~dogsleg@] has joined #debian-emacs
12:05:04<dogsleg> hmmm, looks like it is 3pm EDT, right?
12:06:03<spwhitton> dogsleg: hello!
12:06:08<dogsleg> hi!
12:06:50<spwhitton> let's use gobby
12:06:54<spwhitton> I will create a doc
12:07:57<spwhitton> dogsleg: Teams/Emacsen/dc17 on gobby
12:10:07<dogsleg> i'm in :)
12:11:41<spwhitton> cool.  let's begin with the first item...
12:14:09<dogsleg> hmm, ‘Begin at the beginning,’ the King said gravely, ‘and go on till you come to the end: then stop.’
12:15:06<bremner> imagine music plays while rob types
12:15:40<rlb> wrt the emacs package, I think there's a posibility that bremner might join as a uploader/co-maintainer/whatever.
12:15:51<bremner> ack
12:15:54 * spwhitton is counting himself out due to new job as policy editor.
12:16:09<bremner> item the next?
12:16:44<spwhitton> dogsleg: can we move onto second item?
12:16:53<dogsleg> sure
12:18:01<rlb> We've been exploring the possibilities of droping emacsXY versioning, and just having a single emacs package.  It seems like it's going to work out, and so we've come up with a plan, and are trying to see how it goes.
12:18:38<rlb> I've started poking at the "unversioning" of emacs25, and am going to try to help bremner figure out how to test elpa's behavior in that world.
12:19:17<bremner> the motivation is two-fold; simplify infrastructure, and enforce one emacs version installed
12:19:30<bremner> currently emacs packages accumulate for ever and break things
12:19:40<spwhitton> it's going to cause disruption, but basically no worse than the existing transition to us dh-elpa
12:19:42<spwhitton> use*
12:21:31<bremner> the caveat is people lose the ability to have co-installed versions for testing
12:21:44<bremner> or slow transitions of personal setups.
12:22:16<rlb> Right, you'll have to swtich from say emacs 25 to emacs 26 all at once.
12:22:21<spwhitton> dogsleg: can you foresee any problems we've missed?
12:22:34<spwhitton> dogsleg: you can look at the 
12:22:34<bremner> and probably we will stage emacs in experimental
12:22:37<spwhitton> "master plan
12:22:42<spwhitton> dogsleg: " doc on gobby
12:23:09<dogsleg> looking into it...
12:24:23<dogsleg> why do you need an epoch version number? any priority clash?
12:24:31<spwhitton> dogsleg: emacs-defaults has version 46.0
12:24:41<rlb> s/46/47/
12:24:45<spwhitton> dogsleg: but the new package will have version 25.2.
12:25:31<dogsleg> i see
12:26:00<rlb> Right - we're going to move the "emacs" metapackage to the emacs main source package, and since it's already at 47, we'll need an epoch to make sure the new one fits in.
12:28:16<dogsleg> well, nice plan
12:28:30<dogsleg> i think the main problem is compatibility of addons
12:28:46<spwhitton> dogsleg: say more
12:29:39<bremner> one obvious source of problems is non-dh-elpa addons
12:29:54<dogsleg> but i don't think that there is a somewhat large userbase that require testing several co-installed emacs versions
12:30:41<bremner> building emacs from source is not that hard. even rob can do it ;)
12:31:12<dogsleg> i remember that someone mentioned (here, in irc) that he needed several co-installed emacs versions
12:31:29<spwhitton> dogsleg: do you mean the guy who wanted a GNUstep flavour?
12:31:40<dogsleg> probably, yes
12:31:43<bremner> I believe that was in the bug report about minimum versions
12:32:00<bremner> he mainly didn't want conflicts, which is not problem for /usr/local/bin/emacs
12:33:16<dogsleg> i'd guess that writing an emacs addon and testing it specifically on various _debian_ versions is not a good idea, i'd recommend those people to compile from source, not using precompiled packages
12:34:25<bremner> OK. Anything else to add here? anyone?
12:35:05<spwhitton> okay next topic
12:35:53<dogsleg> so, when do you plan to start? before NMUdiffs for addons not using dh-elpa, after, or simultaneously?
12:36:14<bremner> dogsleg: simultaneously, so we don't ask people to re-upload twice
12:37:10<spwhitton> this is what I thought: (1) fix dh-elpa maintscripts so they don't choke on squashed package (2) NMUdiffs for dropping emacs24 (by means of switching to dh-elpa) (which implicitly rebuilds with new maintscripts)
12:37:28<bremner> also, rebuilding other dh_elpa using packages
12:37:35<bremner> oh wait, that's the other thing
12:38:03<bremner> the other thing = flavour 'emacs'
12:38:07<spwhitton> yes.  it's important to be clear that the emacs24 removal is distinct from the squashing flavours.
12:38:20<spwhitton> david and I worked out a list of emacs24 packges, in "die-emacs24-die" gobby doc
12:38:26<spwhitton> we think we can probably get it done today.
12:38:32<spwhitton> but dogsleg if you have time you could help
12:39:50<spwhitton> the reason for converting to dh-elpa, instead of minimal NMU, is to avoid filing another RC bug during the squashing work
12:39:55<dogsleg> today don't work for me :) since for me it is already tomorrow
12:40:19<bremner> we still need to fix dh_elpa before NMUing?
12:40:39<spwhitton> er, maybe end of tomorrow as still working on dh-elpa.
12:42:21<dogsleg> ok, which help is needed? maybe i'll have some time..
12:42:55<spwhitton> dogsleg: basically, preparing diffs to convert ~10 packages to use dh-elpa.  but not submitting them until dh-elpa 1.10 is released.
12:43:23<spwhitton> dogsleg: best way is if you drop by IRC and ping us, tomorrow, if you have some time (and we are awake)
12:43:28<spwhitton> dogsleg: we will assign something to yyou then :)
12:44:03<dogsleg> ok
12:44:41<spwhitton> next item?
12:45:09<dogsleg> +1
12:45:29<spwhitton> okay.  remainder items are just planning the work we're going to sprint today or tomorrow
12:46:17<spwhitton> emacs-goodies-el!  this is a big one.
12:48:20<spwhitton> any ideas about how we can break it up and convert to dh-elpa?
12:48:59<bremner> do we know how much has real upstream
12:49:28<spwhitton> I would guess less than half
12:49:57<dogsleg> some of them are from and not touched for years
12:50:16<bremner> maybe those can stay in emacs-goodies-el?
12:50:33<bremner> the maintainer did drop markdown-mode when I elpa-ized it
12:50:57<spwhitton> bremner: but we want them to use dh-elpa.
12:51:26<dogsleg> and, by the way, what does maintainer say about breaking it into pieces?
12:52:20<bremner> we haven't really discussed it, except for one or two pieces we replaced
12:52:35<spwhitton> they are mostly inactive, esp. w.r.t. emacs-goodies-el.
12:52:45<dogsleg> in my case #850151 is not closed for almost 8 month
12:52:49-zwiebelbot:#debian-emacs- Debian#850151: emacs-goodies-el: up-to-date version of diminish-el is packaged outside of emacs-goodies-el -
12:55:13<bremner> overriding our newer packages is arguable RC
12:55:28<spwhitton> another example is elserv overwriting elpa-xml-rpc
12:56:24<spwhitton> so this would mean: every time someone packages elpa-foo where foo is also in emacs-goodies-el, emacs-goodies-el gains another RC bug.
12:56:37<bremner> well, maybe we can start by explaining the problem in the bug
12:56:56<bremner> the overriding is not obvious
12:58:11<spwhitton> bremner suggests offering to adopt the package in its current state.
12:58:11<bremner> dogsleg: can you explain the problem of the goodies-el version overriding the elpa one?
12:58:23<spwhitton> ^ in the bug.
12:59:08<spwhitton> (I meant: team-adopting the package)
13:00:01<dogsleg> bremner: i'll try and post it somewhere (e. g. gobby) to check with the team
13:00:07<bremner> dogsleg: great
13:00:54<spwhitton> dogsleg: severity is definitley too low. a tleast important.
13:01:23<spwhitton> so: we're going to set emacs-goodies-el aside until we see maintianer's response in that bug.
13:01:28<dogsleg> will bump it after the appropriate message will be ready
13:01:46<bremner> sounds good.
13:01:56<bremner> the discussion here is to use this bug as a trial
13:02:02<bremner> then maybe think about adopting
13:02:08<spwhitton> next item?
13:02:15<dogsleg> yep
13:02:28<spwhitton> next item is `dh-make-elpa convert` subcommand.
13:02:47<spwhitton> Since the total number of package is only 212, I don't think it's worth investing the time in witing the subcommand.  but perhaps my tolerance for manual packaging is too high?
13:03:17<bremner> maybe see how slow it is to do the rc ones?
13:03:20<spwhitton> (we were expecting more than twice that many packages)
13:03:25<spwhitton> bremner: ah yes, that makes senes.
13:05:50<spwhitton> dogsleg: any thoughts?
13:07:51<dogsleg> i'd suggest to submit rc bugs first and help (by hand) those who will have troubles
13:08:24<spwhitton> dogsleg: we were planning to upload to DELAYED/15 and then submit the NMUdiff as 1st message of bug.
13:10:30<dogsleg> ok, that's probably a big work (given 200 packages), but you think dh-make-elpa convert will work in at least 50% cases?
13:10:50<bremner> dogsleg: oh, we just plan to NMU the 8 rc bugs
13:10:56<bremner> and the rest can follow later
13:11:10<dogsleg> the 204 rest?
13:11:16<bremner> yeah
13:11:23<dogsleg> ohhhh...
13:11:35<spwhitton> dogsleg: yeah, plan to uplaod to DELAYED/15 today/tomorrow is just the emacs24 bugs.
13:12:36<dogsleg> ok, but i thought the current topic is dh-make-elpa convert, isn't it?
13:13:10<bremner> yes, I guess the RC bug conversions are a test case for manual versus automatic
13:14:33<bremner> I seem to be sticking with a strategy of procrastination...
13:15:03<dogsleg> i fear that 'automatic' here rather means 'semi-automatic', or even 'semi-semi-automatic'
13:15:39<bremner> yes
13:16:19<dogsleg> maybe i'm wrong, but the packages lintian listed as not using dh-elpa are so much different, i'd even say unique
13:16:50<bremner> it could be. 
13:17:01<dogsleg> so any automatic tool probably will just break more that fix
13:18:07<spwhitton> dogsleg: right.  this is my assumption.
13:18:12<spwhitton> next item?
13:18:31<dogsleg> y
13:18:46<spwhitton> item is: #869509
13:18:50-zwiebelbot:#debian-emacs- Debian#869509: dh-elpa: please support tuning which emacs flavors to skip -
13:19:08<spwhitton> bremner: do we actually need this, given plans?
13:19:16<bremner> I don't think so.
13:20:02<spwhitton> okay.  so this bug will become wontfix once we do our master plan.
13:20:24<bremner> it's only  wishlist, so we don't really need to say anything more for now
13:20:53<spwhitton> if not wontfix, retitle and mark as fixed by our plans
13:21:24<spwhitton> next item?
13:21:51<dogsleg> y
13:22:04<spwhitton> triage of bugs against emacs24/emacs25.
13:22:58<dogsleg> bremner: currently #869509 is normal, not wishlist
13:23:13-!- sten_ [~sten@] has joined #debian-emacs
13:23:14<bremner> dogsleg: ok. I think it can still sit for a few weeks / months
13:23:33<spwhitton> I guess that the high bug count was the reason I raiesd the possibility of team maintenance.
13:23:35-!- sten_ is now known as sten0
13:25:01<spwhitton> actually, this wasn't meant to be a meeting item.  no decisions to be made.  it was on list of work to sprint and we accidently moved it over to things to discuss.
13:25:59<spwhitton> any other business for this year's meeting?
13:26:34<dogsleg> i don't have anything to discuss
13:29:01<bremner> sten0 is composing a thought
13:33:56<dogsleg> good luck with that, i need to sleep now
13:34:17<bremner> dogsleg: ok, great thanks for participating
13:34:21<spwhitton> this meeting is closed.  see you all next year.


Sean's blog post