all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: ELPA update
Date: Thu, 29 Sep 2011 10:08:26 -0500	[thread overview]
Message-ID: <87d3ejidxx.fsf@lifelogs.com> (raw)
In-Reply-To: 87pqijwid8.fsf@keller.adm.naquadah.org

On Thu, 29 Sep 2011 16:09:07 +0200 Julien Danjou <julien@danjou.info> wrote: 

JD> On Thu, Sep 29 2011, Ted Zlatanov wrote:
>> In Git you can cherry-pick between branches, which makes a new commit ID
>> but the patch contents (including the commit message) are the same.  So
>> that lets you take just one change from one branch to another.  It's not
>> ideal but it's very easy to use and automate.

JD> Let's hope nobody will ever modify more than one file/package in a
JD> commit. Or your strategy will begin to be much more complicated. :)

So far it hasn't been a problem, most non-maintainer commits cover one
thing.

>> If that's too complicated or undesirable in Bazaar and there's no other
>> way to merge just a few commits from one branch to another, I'm open to
>> suggestions.  I still feel, no matter the merge mechanism, that we
>> should use the VCS branch and not the package version as the deciding
>> factor whether to publish a package.

JD> I do not disagree, this is actually kind of how the Linux kernel is
JD> handled if you look at it that way.

Yes, it's a common strategy.  It works well.

JD> But since there's only 2 branches (stable/dev) I'm just not sure it's
JD> the best approach here:
JD> - merging parts of -dev branch into a -stable branch is complicated

No more than managing 20+ package versions, and you have the benefit
that you can publish the branch directly from a cron job.

JD> - tagging a branch when it's ready to be publish with so many packages
JD>   is impossible since developement is happening there on multiple
JD>   packages at the same time

Right, tags are not so good with many moving parts.  Cherry-picking
is better to select only the "ready" pieces for promotion.

JD> At least, the solution to have a set of tags named "{$package}-ready"
JD> which would move on commits will assure that each package is put into
JD> ELPA at the right stage. You can even rollback by moving the tag.
JD> (I'm just not sure bzr can handle that correctly, and that the bzr users
JD> would not make mistakes)

I'm not sure tags would help as much as separate branches, but certainly
it could be beaten into a working state :)

Ted




  reply	other threads:[~2011-09-29 15:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-27 14:25 ELPA update Julien Danjou
2011-09-27 15:53 ` Chong Yidong
2011-09-28  7:48   ` Julien Danjou
2011-09-28  8:41     ` Tassilo Horn
2011-09-28 14:05       ` Stefan Monnier
2011-09-28 17:30         ` Ted Zlatanov
2011-10-12  4:58           ` Stefan Monnier
2011-09-28 13:52     ` Ted Zlatanov
2011-09-28 14:00       ` Julien Danjou
2011-09-28 17:25         ` Ted Zlatanov
2011-09-28 17:28           ` Julien Danjou
2011-09-28 18:43             ` Ted Zlatanov
2011-09-28 20:58             ` Stefan Monnier
2011-09-28 23:01               ` PJ Weisberg
2011-09-29  1:16                 ` Stephen J. Turnbull
2011-09-29  8:45                   ` Ted Zlatanov
2011-09-29 10:14                     ` Julien Danjou
2011-09-29 12:36                       ` Ted Zlatanov
2011-09-29 14:09                         ` Julien Danjou
2011-09-29 15:08                           ` Ted Zlatanov [this message]
2011-09-29 12:26                     ` Stephen J. Turnbull
2011-09-28 14:53       ` Eli Zaretskii
2011-09-29  7:43 ` Jambunathan K
2011-09-29 15:03   ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d3ejidxx.fsf@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.