>>> On 08.10.15 at 16:23, wrote:
> On Thu, Oct 08, 2015 at 06:13:27AM -0600, Jan Beulich wrote:
>> >>> On 08.10.15 at 13:10, wrote:
>> > I fail to get the idea why this would be a problem. Maybe you're seeing
>> > every backport as your sole responsibility? From Xen project's point of
>> > view,
On Thu, Oct 08, 2015 at 06:13:27AM -0600, Jan Beulich wrote:
> >>> On 08.10.15 at 13:10, wrote:
> > On Thu, Oct 08, 2015 at 02:05:51AM -0600, Jan Beulich wrote:
> >> Perhaps there's room for further automation here, yet as with
> >> any automation the question is how quickly getting this in place
On Thu, Oct 08, 2015 at 02:39:40PM +0200, Juergen Gross wrote:
> On 10/08/2015 02:22 PM, Jan Beulich wrote:
> >>>>On 08.10.15 at 13:49, wrote:
> >>On 10/08/2015 01:34 PM, Jan Beulich wrote:
> >>>>>>On 08.10.15 at 12:59, wrote:
> >>&
On 10/08/2015 02:22 PM, Jan Beulich wrote:
On 08.10.15 at 13:49, wrote:
On 10/08/2015 01:34 PM, Jan Beulich wrote:
On 08.10.15 at 12:59, wrote:
Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
Perhaps there's room for further automation here,
>>> On 08.10.15 at 13:49, wrote:
> On 10/08/2015 01:34 PM, Jan Beulich wrote:
>>>>> On 08.10.15 at 12:59, wrote:
>>> Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
>>>> Perhaps there's room for further a
>>> On 08.10.15 at 13:10, wrote:
> On Thu, Oct 08, 2015 at 02:05:51AM -0600, Jan Beulich wrote:
>> Perhaps there's room for further automation here, yet as with
>> any automation the question is how quickly getting this in place
>> will amortize itself.
>>
>
> Building every commit can be easily
On 10/08/2015 01:34 PM, Jan Beulich wrote:
On 08.10.15 at 12:59, wrote:
Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
Perhaps there's room for further automation here, yet as with
any automation the question is how quickly getting this in plac
>>> On 08.10.15 at 12:39, wrote:
> On 08/10/15 09:05, Jan Beulich wrote:
> On 07.10.15 at 19:45, wrote:
>>> The steady state for "R9 S3 {18,36}" is to have 2 releases receiving
>>> bug fixes, and 2 releases receiving security fixes at any given time;
>>> and this happens every 3 months; total
>>> On 08.10.15 at 12:59, wrote:
> Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
>> Perhaps there's room for further automation here, yet as with
>> any automation the question is how quickly getting this in place
>> wil
On Thu, Oct 08, 2015 at 02:05:51AM -0600, Jan Beulich wrote:
> >>> On 07.10.15 at 19:45, wrote:
[...]
>
> > But it's worth asking
> > whether that is actually the case. It has been argued, for instance,
> > that the difficulty in backporting a patch scales with the distance in
> > commits that
On 08/10/15 09:05, Jan Beulich wrote:
>> It has so far been assumed in this discussion that this would be an
>> undue burden, and therefore not acceptable.
>
> I don't think anyone said "undue". All that was said was that the
> amount of work to be put into this increases.
I think it's worth sayi
Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
> What I consider more of an issue is the tedious (because purely
> mechanical) task of committing the patches to the respective stable
> trees, which (in my way of doing it) implies test builds for e
On 08/10/15 09:05, Jan Beulich wrote:
On 07.10.15 at 19:45, wrote:
>> OK, so we have to decide on a *set* of factors, rather than just one.
>>
>> Let's try to be analytic.
>>
>> So we have so far identified 4 "parameters" that we can tweak:
>>
>> 1. Release frequency. At the moment, this is
>>> On 07.10.15 at 19:56, wrote:
> On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich wrote:
> On 06.10.15 at 13:07, wrote:
>>> A majority of developers express interests in trying a shorter release
>>> cycle -- to change from 9 months to 6 months [0]. There are, however,
>>> repercussions on how w
>>> On 07.10.15 at 19:45, wrote:
> OK, so we have to decide on a *set* of factors, rather than just one.
>
> Let's try to be analytic.
>
> So we have so far identified 4 "parameters" that we can tweak:
>
> 1. Release frequency. At the moment, this is "9 months".
> 2. Length of time bug fixes a
On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich wrote:
On 06.10.15 at 13:07, wrote:
>> A majority of developers express interests in trying a shorter release
>> cycle -- to change from 9 months to 6 months [0]. There are, however,
>> repercussions on how we manage stable and possible LTS release
On Tue, Oct 6, 2015 at 3:52 PM, Jan Beulich wrote:
On 06.10.15 at 16:09, wrote:
>> What do you propose when we regarding stable branches when we switch to
>> 6 months cycle?
>
> See the chicken-and-egg problem: I can't answer this, because the
> issues with the stable trees are the main reas
On Tue, 2015-10-06 at 17:25 +0100, Wei Liu wrote:
> It could be an alias for all maintainers. Making sure a patch contains
> CC stable@ is good enough for searching through git log for candidates.
Ah yes, I suppose the Linux folks use git log --grep=stable@vger a lot,
which does a bunch of the wor
On Tue, Oct 06, 2015 at 02:10:05PM +0100, Ian Campbell wrote:
> On Tue, 2015-10-06 at 12:07 +0100, Wei Liu wrote:
> > 2. What to do with the non-LTS releases?
> >
> > I think they should still be considered stable releases for some
> > time. I'm just not sure for how long they should receive updat
On Tue, 2015-10-06 at 12:07 +0100, Wei Liu wrote:
> Hi all
>
> A majority of developers express interests in trying a shorter
> release
> cycle -- to change from 9 months to 6 months [0]. There are, however,
> repercussions on how we manage stable and possible LTS releases.
>
> I start this threa
On Tue, Oct 06, 2015 at 08:52:23AM -0600, Jan Beulich wrote:
> >>> On 06.10.15 at 16:09, wrote:
> > What do you propose when we regarding stable branches when we switch to
> > 6 months cycle?
>
> See the chicken-and-egg problem: I can't answer this, because the
> issues with the stable trees are
>>> On 06.10.15 at 16:09, wrote:
> What do you propose when we regarding stable branches when we switch to
> 6 months cycle?
See the chicken-and-egg problem: I can't answer this, because the
issues with the stable trees are the main reason I don't support the
change to the release cycle (yet).
J
>>> On 06.10.15 at 16:12, wrote:
> On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich wrote:
>> I'm not sure if it's still that way nowadays, but in the years after
>> stable and long term releases got introduced in Linux even long
>> term branches weren't all equal: The general stable tree maintainer
>
On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich wrote:
> I'm not sure if it's still that way nowadays, but in the years after
> stable and long term releases got introduced in Linux even long
> term branches weren't all equal: The general stable tree maintainer
> actively argued against the use of cer
On Tue, Oct 06, 2015 at 07:38:30AM -0600, Jan Beulich wrote:
> >>> On 06.10.15 at 13:07, wrote:
> > A majority of developers express interests in trying a shorter release
> > cycle -- to change from 9 months to 6 months [0]. There are, however,
> > repercussions on how we manage stable and possibl
>>> On 06.10.15 at 13:07, wrote:
> A majority of developers express interests in trying a shorter release
> cycle -- to change from 9 months to 6 months [0]. There are, however,
> repercussions on how we manage stable and possible LTS releases.
I find it kind of odd to try to answer question 2 (c
On Tue, Oct 06, 2015 at 12:07:58PM +0100, Wei Liu wrote:
> Hi all
>
> A majority of developers express interests in trying a shorter release
> cycle -- to change from 9 months to 6 months [0]. There are, however,
> repercussions on how we manage stable and possible LTS releases.
>
> I start this
On Tue, 2015-10-06 at 12:07 +0100, Wei Liu wrote:
> 2. What to do with the non-LTS releases?
>
> I think they should still be considered stable releases for some
> time. I'm just not sure for how long they should receive updates. One
> way of looking at them is to use the same concept as Linux --
On 06/10/15 12:07, Wei Liu wrote:
> Hi all
>
> A majority of developers express interests in trying a shorter release
> cycle -- to change from 9 months to 6 months [0]. There are, however,
> repercussions on how we manage stable and possible LTS releases.
>
> I start this thread hoping it's clea
Hi all
A majority of developers express interests in trying a shorter release
cycle -- to change from 9 months to 6 months [0]. There are, however,
repercussions on how we manage stable and possible LTS releases.
I start this thread hoping it's clearer that downstream consumers like
distributions
30 matches
Mail list logo
