Re: ELPA update

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 28 Sep 2011 19:28:44 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Wed, Sep 28 2011, Ted Zlatanov wrote:
JD> Well, in our case I'll take commit = package upload.

Right, I see the utility of an immediate deployment, but I don't think
your commit should deploy my package.  Let's see what Stefan and Chong
think.  See below...

>> Yes, but you can't commit changes to someone else's package, can you?

JD> Yes, you can on exceptional circumstances (critical bugs), it's called a
JD> NMU (Non-Maintainer Upload).

We can have that too, with Stefan and Chong (and possibly me and anyone
else with shell access to the GNU ELPA webserver) enabled to do it.  But
not for everyone, I hope!  And see below for a more flexible approach...

>> And they don't roll out commits immediately, there's a release process?

JD> Every packages goes in the unstable distribution, and then the release
JD> process takes 2 years, so it's not a valid model to copy. ;-)

I think a 2-stage release process would be a very good thing.  For our
purposes it's enough to have an unstable stage, which could simply be
the "elpa" branch.  So developers would commit to "elpa", test it all
they want, then merge into "elpa-dev".  That merge, if the commit is
signed and the commit targets the right packages for the private keys,
would kick off the deployment; otherwise it would start the approval
queue process.  Eventually a maintainer would push to "elpa-stable" with
a release cycle of at least 3 months (maybe synchronized to Emacs
releases).  Regular committers can't push to "elpa-stable".

Users can point to the "elpa" or "elpa-dev" branched directly with 
`make site' if they want to use them, but otherwise they would use
"elpa-stable".  The GNU ELPA web site would offer the dev and stable
branches.

The 2-year cycle is too long, but I think 3 months is reasonable.  We
have a responsibility to our users to treat GNU ELPA package releases as
seriously as we treat Emacs itself, so this proposal is IMO a good
compromise between fast releases for the developers and stability for
the users.

Ted