ELPA new package timidity

ELPA new package timidity

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

Recently (a week or two ago), i added ascii-art-to-unicode.el to GNU
ELPA as package ‘ascii-art-to-unicode’.  This was accomplished in one
commit, having previously made the adaptations to ELPA from the previous
released version locally.  After a day or so, i saw that the package
appears in the "list of packages" page, with the proper version number.
Cool.

Now, i would like to add gnugo.el and some related files as package
‘gnugo’, but this time, i'd like to do the adaptations publicly, over
several commits.  In this case, it would be unseemly to have the package
appear in the list of packages during this phase.  I understand that the
ELPA maintenance scripts trigger on change of ‘Version’ header, from
this packages/README excerpt:

  This cron job only creates a new package when the "version" (as
  specified in the foo-pkg.el or in the "Version:" header) of a package
  is modified.  This means that you can safely work on the next version
  here without worrying about the unstable code making it to GNU ELPA,
  and simply update the "version" when you want to release the new code.

But it's not clear to me that the initial commit, where ‘Version’ makes
the transition from non-existent to existing-but-not-ready-yet, won't
trigger the new-package process.  In sum, steady-state OKAY, boundary
condition behavior HMMM.  So, given

  A -- B -- C -- D

where A through C have the "work in progress" version and D has the
"fully adapted" version, what must i do to ensure that only D triggers
the "new package" process, and not A through C?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: ELPA new package timidity

[Stefan Monnier]

> But it's not clear to me that the initial commit, where ‘Version’ makes
> the transition from non-existent to existing-but-not-ready-yet, won't
> trigger the new-package process.  In sum, steady-state OKAY, boundary

Indeed, that's a missing feature.
I guess we could make "Version: -1" mean "don't release it".


        Stefan

Re: ELPA new package timidity

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Mon, 27 Jan 2014 19:10:53 -0500

   Indeed, that's a missing feature.
   I guess we could make "Version: -1" mean "don't release it".

Another idea is to push onto a public branch that is declared
"ephemeral" (subject to rebase and eventual removal), but otherwise
ignored by the cron job.  I would prefer this way, if it's possible.

OK, i have just now verified that it is possible to create a branch
‘ttn-gnugo’ and delete it.  For both operations, i saw:

 remote: Sending notification emails to: ADDRESS

Hopefully the cron job is not confused by those notifications and the
ephemeral branch itself.  (Is the cron job publicly viewable, btw?)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: ELPA new package timidity

[Stefan Monnier]

> Another idea is to push onto a public branch that is declared
> "ephemeral" (subject to rebase and eventual removal), but otherwise
> ignored by the cron job.  I would prefer this way, if it's possible.

Yes, that's fine.

> Hopefully the cron job is not confused by those notifications and the
> ephemeral branch itself.  (Is the cron job publicly viewable, btw?)

It's admin/update-archive.sh in the `elpa' branch (except it's not
auto-updated by commits, I update it by hand every once in a while).


        Stefan

Re: ELPA new package timidity

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Tue, 28 Jan 2014 08:03:35 -0500

   It's admin/update-archive.sh in the `elpa' branch (except it's not
   auto-updated by commits, I update it by hand every once in a while).

OK, i see now.  Thanks.  Full-speed ahead...

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

Re: ELPA new package timidity

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

() Thien-Thi Nguyen <ttn@gnu.org>
() Tue, 28 Jan 2014 16:41:44 +0100

   Full-speed ahead...

I have just pushed a rebased branch ‘ttn-gnugo’.  Please take a look
anyone interested in co- (and eventually fully-) maintaining gnugo.el
in ELPA.  Feedback requested, especially on the "musings" in HACKING.

If All Goes Well, the plan is to release 2.2.15 mid-February or so.  At
that time i will also withdraw as maintainer, announcing a successor
(presuming i find one :-D).  If you fancy yourself playing that role,
please feel free to tell me your thoughts in private mail -- include
"gnugo maint" in the subject.  The directory:

 http://www.gnuvola.org/z.3MzFQeDd/

has some additional material mentioned in HACKING.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]