[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
From:       Peter Volkov <peter.volkov () gmail ! com>
Date:       2017-07-31 16:51:29
Message-ID: CAE+k_g+=14+=V-mObsQ5qNt98Lm_ehnCqp9v_rr_5p8Qyj6Ung () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jul 31, 2017 at 6:11 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <antarus@gentoo.org> wrote:
> > Sorry, to be clear the conclusion I was hoping to draw is that one has 2
> > repos instead of 1.
> >
> > 1) Rolling.
> > 2) Stable.
> >
> > Rolling is typical ~arch Gentoo. People in rolling can do whatever they
> > want; they can't affect stable at all.
> >
> > Stable is an entirely separate repo, a fork, where CPVs are pulled from
> > Rolling into Stable. If Stable wants to keep a gnarly old version of some
> > package around; great! But the rolling people don't have to care.
> >
>
> This seems like it would be fairly painful to maintain.  You'd need to
> constantly pull in new packages, and prune out old ones.  It would
> duplicate many of the functions maintainers already do.  I doubt
> anybody would go to the trouble to make this happen.
>

Long time ago releng team did something similar. We defined stable as
tested distribution that has all security updates merged back. From my
experience what made that efforts very tedious was that there were packages
that do not specify minimum required versions for dependencies. Thus we had
to duplicate maintainer's work and check lot's of dependencies again.

Also when we speak about stable tree we first should define what stability
are we talking about? What do we guarantee? ABI/API compatibility or that
it is expected "just work" (whatever this means)?

--
Peter.

[Attachment #3 (text/html)]

<div dir="ltr">On Mon, Jul 31, 2017 at 6:11 PM, Rich Freeman <span dir="ltr">&lt;<a \
href="mailto:rich0@gentoo.org" target="_blank">rich0@gentoo.org</a>&gt;</span> \
wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mon, Jul 31, 2017 at 10:52 \
AM, Alec Warner &lt;<a href="mailto:antarus@gentoo.org">antarus@gentoo.org</a>&gt; \
wrote:<br> &gt; Sorry, to be clear the conclusion I was hoping to draw is that one \
has 2<br> &gt; repos instead of 1.<br>
&gt;<br>
&gt; 1) Rolling.<br>
&gt; 2) Stable.<br>
&gt;<br>
&gt; Rolling is typical ~arch Gentoo. People in rolling can do whatever they<br>
&gt; want; they can&#39;t affect stable at all.<br>
&gt;<br>
&gt; Stable is an entirely separate repo, a fork, where CPVs are pulled from<br>
&gt; Rolling into Stable. If Stable wants to keep a gnarly old version of some<br>
&gt; package around; great! But the rolling people don&#39;t have to care.<br>
&gt;<br>
<br>
</span>This seems like it would be fairly painful to maintain.   You&#39;d need \
to<br> constantly pull in new packages, and prune out old ones.   It would<br>
duplicate many of the functions maintainers already do.   I doubt<br>
anybody would go to the trouble to make this happen.<span class="gmail-HOEnZb"><font \
color="#888888"><br></font></span></blockquote><div><br></div><div>Long time ago \
releng team did something similar. We defined stable as tested distribution that has \
all security updates merged back. From my experience what made that efforts very \
tedious was that there were packages that do not specify minimum required versions \
for dependencies. Thus we had to duplicate maintainer&#39;s work and check lot&#39;s \
of dependencies again.<br><br></div><div>Also when we speak about stable tree we \
first should define what stability are we talking about? What do we guarantee? \
ABI/API compatibility or that it is expected &quot;just work&quot; (whatever this \
means)?<br></div></div><br>--<br></div><div \
class="gmail_extra">Peter.<br></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]