From: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
To: Vivek Goyal <vgoyal@redhat.com>, Simon Horman <horms@verge.net.au>
Cc: Dave Young <dyoung@redhat.com>,
Kexec Mailing List <kexec@lists.infradead.org>,
WANG Chao <chaowang@redhat.com>
Subject: Re: More frequent kexec-tools releases
Date: Wed, 29 Jan 2014 09:36:38 +0800 [thread overview]
Message-ID: <52E85B26.2080203@cn.fujitsu.com> (raw)
In-Reply-To: <20140128184042.GA7098@redhat.com>
Hello
On 01/29/2014 02:40 AM, Vivek Goyal wrote:
> Hi All,
>
> Just now we were discussing that fedora kexec-tools should rebase to
> upstream kexec-tools every release so that we can test the latest code
> sooner.
>
> Then Dave Young pulled in some data about the kexec-tools release
> duration.
>
> Date: Tue Mar 19 10:46:46 2013 +0900
> kexec-tools 2.0.4 ~100 commits
>
> Date: Mon Jan 16 09:15:25 2012 +1100
> kexec-tools 2.0.3 ~100 commits
>
> Date: Thu Jul 29 13:40:00 2010 +0900
> kexec-tools 2.0.2 ~80 commits
>
> Date: Thu Aug 13 09:28:08 2009 +1000
> kexec-tools 2.0.1 ~60 commits
>
> Date: Sat Jul 19 10:31:30 2008 +1000
> kexec-tools 2.0.0
>
> So that is 5 release in 5.5 years. It is roughly 1 release per year.
>
> I am wondering if there is any interest in more frequent releases of
> kexec-tools. Say every 3 months or every 6 months.
>
> IMHO, it might be better if there are more frequent release of kexec-tools
> (say a release every 6 months) and then every 6 months distributions
> should be able to rebase to that new release.
>
> Thoughts?
Agreed. Sometimes, important changes in the kernel side will lead to the change
in the kexec-tools, so especially in this case, I think it might be better
to release a new version asap.
>
> Thanks
> Vivek
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
--
Thanks.
Zhang Yanfei
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-01-29 1:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-28 18:40 More frequent kexec-tools releases Vivek Goyal
2014-01-29 1:36 ` Zhang Yanfei [this message]
2014-01-29 14:23 ` Vivek Goyal
2014-01-31 5:23 ` Simon Horman
2014-01-31 14:30 ` Vivek Goyal
2014-02-04 8:31 ` Simon Horman
2014-02-04 12:41 ` Simon Horman
2014-02-04 14:31 ` Vivek Goyal
2014-02-05 1:12 ` Zhang Yanfei
2014-02-05 6:49 ` Simon Horman
2014-02-05 13:20 ` Vivek Goyal
2014-02-06 1:55 ` Simon Horman
2014-02-06 14:23 ` Vivek Goyal
2014-02-06 23:58 ` Simon Horman
2014-02-07 2:20 ` Dave Young
2014-02-07 14:34 ` Vivek Goyal
2014-02-12 1:16 ` Simon Horman
2014-02-25 4:12 ` WANG Chao
2014-01-29 16:46 ` Khalid Aziz
2014-01-29 16:52 ` Vivek Goyal
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=52E85B26.2080203@cn.fujitsu.com \
--to=zhangyanfei@cn.fujitsu.com \
--cc=chaowang@redhat.com \
--cc=dyoung@redhat.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=vgoyal@redhat.com \
/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.
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.