[gentoo-dev] About reducing or even removing stable tree for some arches

[gentoo-dev] About reducing or even removing stable tree for some arches

[Pacho Ramos]

Hello

Every day I am hitting tons of blockers stabilizations and keywording
requests for alpha, sparc, ia64, ppc and ppc64. 

Again, I would suggest to either decrease radically the amount of stable
packages of some of that arches or even make them testing only.

For reducing their stable tree, my suggestion would be to either keep
their current stage3 packages stable or stage3+some concrete (and
public) list of packages.

Currently situation is not good at all as we rely on mostly one member
needing to handle most stable work and, if any stablereq has any issue
leading to it not being able to be handled in an "automated" way, the
bug gets blocked for months. Also, keywording work is mostly stalled on
this arches as it's done by even less people.

The current policy of maintainers dropping keywords after 90 days is
simply not applied because it leads up to that maintainer needing to
kill himself that keyword and ALL the reverse deps keywords and, then,
all that effort should probably be replaced by making the opposite, I
mean, reducing the stable tree of that arches to a minimum and moving
all the other packages to testing. The main advantage of this is that it
needs maybe more effort in one round but it solves the problem for the
future. On the other hand trying to kill keywords of a package *and all
its reverse deps* requires a lot of work every time the problem appears.

Of course I volunteer for doing the work of reducing that stable trees
if relevant arch teams agree.

Thanks a lot for your help

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Rich Freeman]

On Mon, Feb 16, 2015 at 8:34 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>
> The current policy of maintainers dropping keywords after 90 days is
> simply not applied because it leads up to that maintainer needing to
> kill himself that keyword and ALL the reverse deps keywords

A published script might ease that, especially with the move to git
(where that could be done in a single commit).

Another option is to just allow the keywords to be dropped without
fixing the reverse deps on those archs in these circumstances, though
that can be messier for users.

-- 
Rich

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Pacho Ramos]

El lun, 16-02-2015 a las 10:09 -0500, Rich Freeman escribió:
> On Mon, Feb 16, 2015 at 8:34 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> >
> > The current policy of maintainers dropping keywords after 90 days is
> > simply not applied because it leads up to that maintainer needing to
> > kill himself that keyword and ALL the reverse deps keywords
> 
> A published script might ease that, especially with the move to git
> (where that could be done in a single commit).

That looks interesting... but I don't think we should wait until git
migration is done. Well, since I joined at 2009 I am earing about git
migration and it's never done, then, I would do that job (even manually
with CVS and tons of commits) without waiting for git.

> 
> Another option is to just allow the keywords to be dropped without
> fixing the reverse deps on those archs in these circumstances, though
> that can be messier for users.
> 

Yeah, that is another option... but I think that it can be worse for the
users as, instead of they reading a news item informing about tons of
packages being now moved to testing (or all their tree) and they
preparing to that, they will start to get portage errors from time to
time depending on their installed packages :/

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Anthony G. Basile]

On 02/16/15 08:34, Pacho Ramos wrote:
> Hello
>
> Every day I am hitting tons of blockers stabilizations and keywording
> requests for alpha, sparc, ia64, ppc and ppc64.

The powerpc team figured we'd deal with this by being "lax" about 
keywording/stabilization and catch problems in subsequent bug reports to 
increase our throughput.  We didn't want to drop the entire arch to ~.   
The team hasn't met since last august, and we should discuss this 
again.  But we decided then that ago would do stabilization and the rest 
of us would do keywording.

As far as I'm concerned, I'm happy to drop all desktop-ish packages to 
~arch, but keep the more server-ish, system-ish packages as stable.  
Controlling @system with stable keywords is very useful for building 
stages so I'm reluctant to give that up.  So maybe we can just adopt the 
policy that any ppc/ppc64 package which depends on X can be dropped to ~.

> Thanks a lot for your help
>

No problem.  Can you categorize where most of the blockers are coming 
from?  Are they mostly desktop?

Comments from other ppc people?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Joshua Kinard]

On 02/16/2015 10:36, Anthony G. Basile wrote:
> On 02/16/15 08:34, Pacho Ramos wrote:
>> Hello
>>
>> Every day I am hitting tons of blockers stabilizations and keywording
>> requests for alpha, sparc, ia64, ppc and ppc64.
> 
> The powerpc team figured we'd deal with this by being "lax" about
> keywording/stabilization and catch problems in subsequent bug reports to
> increase our throughput.  We didn't want to drop the entire arch to ~.   The
> team hasn't met since last august, and we should discuss this again.  But we
> decided then that ago would do stabilization and the rest of us would do
> keywording.
> 
> As far as I'm concerned, I'm happy to drop all desktop-ish packages to ~arch,
> but keep the more server-ish, system-ish packages as stable.  Controlling
> @system with stable keywords is very useful for building stages so I'm
> reluctant to give that up.  So maybe we can just adopt the policy that any
> ppc/ppc64 package which depends on X can be dropped to ~.

:: puts on a flame-retardant suit ::

Once we complete the git migration, why not take a second look on using a
stable/testing/unstable (or -RELEASE/-STABLE/-CURRENT) system used by Debian
and FreeBSD?  That should be entirely doable under a git tree versus CVS.  It
would require beefing releng up again and a whole host of other issues.

Keep the core git tree constantly rolling forward, have a dedicated branch get
cut say, once a year (or less -- Debian is ~18mo?), another group of devs works
on stabilizing that (and periodically cherrypicking from the master branch),
and when the time comes, totally freeze that for security revs only by a
smaller group of devs?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Rich Freeman]

On Mon, Feb 16, 2015 at 10:59 AM, Joshua Kinard <kumba@gentoo.org> wrote:
>
> Keep the core git tree constantly rolling forward, have a dedicated branch get
> cut say, once a year (or less -- Debian is ~18mo?), another group of devs works
> on stabilizing that (and periodically cherrypicking from the master branch),
> and when the time comes, totally freeze that for security revs only by a
> smaller group of devs?

That might actually make sense for the minor archs.  I'm not sure how
popular it would be though for amd64.  I doubt I'd use it. I think one
of the big benefits of Gentoo stable is that you can have a fairly
mature core system, but still track bleeding-edge for specific
packages you're interested in.  You can't really do that with almost
any other distro.  I might want to use a live version of chromium if I
contribute to it, but I don't want that new release of KDE that
everybody says is buggy, etc (contrived example - I've almost
forgotten about 4.0 now).

If we were going to be more release-based it might make more sense to
do it in the sense of CI.  Maybe have a daily release and a live
branch, with the former being the intended target for a typical user.
The daily release would be tested automatically before it was actually
released (obviously this can only be done to a limited extent).  The
overall experience wouldn't change much, but at least the daily
emerge-webrsync user would be assured to not have glaring keyword
errors and such in their tree that repoman would catch.

-- 
Rich

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Christopher Head]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

On Mon, 16 Feb 2015 10:59:06 -0500
Joshua Kinard <kumba@gentoo.org> wrote:

> Once we complete the git migration, why not take a second look on
> using a stable/testing/unstable (or -RELEASE/-STABLE/-CURRENT) system
> used by Debian and FreeBSD?  That should be entirely doable under a
> git tree versus CVS.  It would require beefing releng up again and a
> whole host of other issues.
> 
> Keep the core git tree constantly rolling forward, have a dedicated
> branch get cut say, once a year (or less -- Debian is ~18mo?),
> another group of devs works on stabilizing that (and periodically
> cherrypicking from the master branch), and when the time comes,
> totally freeze that for security revs only by a smaller group of devs?

Personally, one of the things that I love about Gentoo is that I never
have to deal with EVERYTHING changing all at once. Sure, things may
change more often through the year than they do with staged releases,
but it’s all spread out over the year, so that in any given week, what
changes is a nice, bite-sized chunk of my system, so that I can easily
isolate and deal with any problems—rather than a staged release that
upgrades 150 packages, leaving a dozen things broken and no idea where
to start looking.

Also, from a more pragmatic point of view, I don’t particularly want to
have to *compile* a year’s worth of new packages at one moment in
time—better to spend an hour here, an hour there, spread out over the
weeks.
-- 
Christopher Head

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Pacho Ramos]

El lun, 16-02-2015 a las 10:36 -0500, Anthony G. Basile escribió:
> On 02/16/15 08:34, Pacho Ramos wrote:
> > Hello
> >
> > Every day I am hitting tons of blockers stabilizations and keywording
> > requests for alpha, sparc, ia64, ppc and ppc64.
> 
> The powerpc team figured we'd deal with this by being "lax" about 
> keywording/stabilization and catch problems in subsequent bug reports to 
> increase our throughput.  We didn't want to drop the entire arch to ~.   
> The team hasn't met since last august, and we should discuss this 
> again.  But we decided then that ago would do stabilization and the rest 
> of us would do keywording.
> 
> As far as I'm concerned, I'm happy to drop all desktop-ish packages to 
> ~arch, but keep the more server-ish, system-ish packages as stable.  
> Controlling @system with stable keywords is very useful for building 
> stages so I'm reluctant to give that up.  So maybe we can just adopt the 
> policy that any ppc/ppc64 package which depends on X can be dropped to ~.
> 

Would you mind generating a list of installed packages do you have now
currently on your ppc* boxes? That would be a good start point to know
what to preserve :) (I remember I was able to found the list of packages
in stage3 some months ago but I am now unable to :S)

> > Thanks a lot for your help
> >
> 
> No problem.  Can you categorize where most of the blockers are coming 
> from?  Are they mostly desktop?
> 

They come from multiple places, for example I am now fighting with
getting ipython finally stabilized after months of waiting because the
deps hell in python packages (as package A needs package B, B needs C
and D maintained by others... and the chain keeps growing and growing).

With the current way of passing the stabilization responsibility to
mostly Ago the problem is that he needs to do stabilization in a more
"automatized" way as he needs to take care of a lot of arches (all but
hppa). Then, most of this bugs get stalled forever as we cannot rely on
any arch team member apart of him to take care of trying to do that job.
And because of this not only minor arches, even amd64 is blocked by
this.

On the other hand, arm team has already being able to do that one as his
arch team members have found all the needed packages to stabilize by
themselves for ARM :|
 
> Comments from other ppc people?
> 

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Anthony G. Basile]

On 02/16/15 11:05, Pacho Ramos wrote:
> El lun, 16-02-2015 a las 10:36 -0500, Anthony G. Basile escribió:
>> On 02/16/15 08:34, Pacho Ramos wrote:
>>> Hello
>>>
>>> Every day I am hitting tons of blockers stabilizations and keywording
>>> requests for alpha, sparc, ia64, ppc and ppc64.
>> The powerpc team figured we'd deal with this by being "lax" about
>> keywording/stabilization and catch problems in subsequent bug reports to
>> increase our throughput.  We didn't want to drop the entire arch to ~.
>> The team hasn't met since last august, and we should discuss this
>> again.  But we decided then that ago would do stabilization and the rest
>> of us would do keywording.
>>
>> As far as I'm concerned, I'm happy to drop all desktop-ish packages to
>> ~arch, but keep the more server-ish, system-ish packages as stable.
>> Controlling @system with stable keywords is very useful for building
>> stages so I'm reluctant to give that up.  So maybe we can just adopt the
>> policy that any ppc/ppc64 package which depends on X can be dropped to ~.
>>
> Would you mind generating a list of installed packages do you have now
> currently on your ppc* boxes? That would be a good start point to know
> what to preserve :) (I remember I was able to found the list of packages
> in stage3 some months ago but I am now unable to :S)

Yes and no.  I'd like to hear from the other ppc team members, otherwise 
you'll just get my wish list.

>
>>> Thanks a lot for your help
>>>
>> No problem.  Can you categorize where most of the blockers are coming
>> from?  Are they mostly desktop?
>>
> They come from multiple places, for example I am now fighting with
> getting ipython finally stabilized after months of waiting because the
> deps hell in python packages (as package A needs package B, B needs C
> and D maintained by others... and the chain keeps growing and growing).

Ah yes.  The python and ruby dep hell.



-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Mike Gilbert]

On Mon, Feb 16, 2015 at 4:22 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> They come from multiple places, for example I am now fighting with
>> getting ipython finally stabilized after months of waiting because the
>> deps hell in python packages (as package A needs package B, B needs C
>> and D maintained by others... and the chain keeps growing and growing).
>
>
> Ah yes.  The python and ruby dep hell.

I suspect the python depgraph gets a lot bigger when you include
testing-related deps. It might be worth use-masking test on some of
the smaller archs.

If anyone thinks that's a good/bad idea, it would be nice to hear about it.

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

On Mon, Feb 16, 2015 at 02:34:50PM +0100, Pacho Ramos wrote:
> Hello
> 
> Every day I am hitting tons of blockers stabilizations and keywording
> requests for alpha, sparc, ia64, ppc and ppc64. 
> 
> Again, I would suggest to either decrease radically the amount of stable
> packages of some of that arches or even make them testing only.
> 
> For reducing their stable tree, my suggestion would be to either keep
> their current stage3 packages stable or stage3+some concrete (and
> public) list of packages.
> 
> Currently situation is not good at all as we rely on mostly one member
> needing to handle most stable work and, if any stablereq has any issue
> leading to it not being able to be handled in an "automated" way, the
> bug gets blocked for months. Also, keywording work is mostly stalled on
> this arches as it's done by even less people.
> 
> The current policy of maintainers dropping keywords after 90 days is
> simply not applied because it leads up to that maintainer needing to
> kill himself that keyword and ALL the reverse deps keywords and, then,
> all that effort should probably be replaced by making the opposite, I
> mean, reducing the stable tree of that arches to a minimum and moving
> all the other packages to testing. The main advantage of this is that it
> needs maybe more effort in one round but it solves the problem for the
> future. On the other hand trying to kill keywords of a package *and all
> its reverse deps* requires a lot of work every time the problem appears.

I think the cleanest way forward would be to mark these arch's dev or
exp in the profiles. That way, maintainers don't have to worry about
them and the people maintaining the arch's can determine what needs to
be stabilized at their own paces.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

Dnia 2015-02-16, o godz. 10:37:12
William Hubbs <williamh@gentoo.org> napisał(a):

> On Mon, Feb 16, 2015 at 02:34:50PM +0100, Pacho Ramos wrote:
> > Hello
> > 
> > Every day I am hitting tons of blockers stabilizations and keywording
> > requests for alpha, sparc, ia64, ppc and ppc64. 
> > 
> > Again, I would suggest to either decrease radically the amount of stable
> > packages of some of that arches or even make them testing only.
> > 
> > For reducing their stable tree, my suggestion would be to either keep
> > their current stage3 packages stable or stage3+some concrete (and
> > public) list of packages.
> > 
> > Currently situation is not good at all as we rely on mostly one member
> > needing to handle most stable work and, if any stablereq has any issue
> > leading to it not being able to be handled in an "automated" way, the
> > bug gets blocked for months. Also, keywording work is mostly stalled on
> > this arches as it's done by even less people.
> > 
> > The current policy of maintainers dropping keywords after 90 days is
> > simply not applied because it leads up to that maintainer needing to
> > kill himself that keyword and ALL the reverse deps keywords and, then,
> > all that effort should probably be replaced by making the opposite, I
> > mean, reducing the stable tree of that arches to a minimum and moving
> > all the other packages to testing. The main advantage of this is that it
> > needs maybe more effort in one round but it solves the problem for the
> > future. On the other hand trying to kill keywords of a package *and all
> > its reverse deps* requires a lot of work every time the problem appears.
> 
> I think the cleanest way forward would be to mark these arch's dev or
> exp in the profiles. That way, maintainers don't have to worry about
> them and the people maintaining the arch's can determine what needs to
> be stabilized at their own paces.

Sounds like a very bad idea. This will only cause developers to
frequently break the tree accidentally because of no repoman checks
by default.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] About reducing or even removing stable tree for some arches

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Mon, Feb 16, 2015 at 02:34:50PM +0100, Pacho Ramos wrote:
> Hello
> 
> Every day I am hitting tons of blockers stabilizations and keywording
> requests for alpha, sparc, ia64, ppc and ppc64. 
> 
> Again, I would suggest to either decrease radically the amount of stable
> packages of some of that arches or even make them testing only.
> 
> For reducing their stable tree, my suggestion would be to either keep
> their current stage3 packages stable or stage3+some concrete (and
> public) list of packages.
> 
> Currently situation is not good at all as we rely on mostly one member
> needing to handle most stable work and, if any stablereq has any issue
> leading to it not being able to be handled in an "automated" way, the
> bug gets blocked for months. Also, keywording work is mostly stalled on
> this arches as it's done by even less people.
> 
> The current policy of maintainers dropping keywords after 90 days is
> simply not applied because it leads up to that maintainer needing to
> kill himself that keyword and ALL the reverse deps keywords and, then,
> all that effort should probably be replaced by making the opposite, I
> mean, reducing the stable tree of that arches to a minimum and moving
> all the other packages to testing. The main advantage of this is that it
> needs maybe more effort in one round but it solves the problem for the
> future. On the other hand trying to kill keywords of a package *and all
> its reverse deps* requires a lot of work every time the problem appears.
> 
> Of course I volunteer for doing the work of reducing that stable trees
> if relevant arch teams agree.

I responded to this earlier, but I don't know what  happened to my
message since I didn't see it come back.

I propose that we look at switching these arch's to dev or exp in the
profiles. That way these arch teams can independently stabilize packages
they wish to stabilize without holding up the rest of us.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-dev] Re: About reducing or even removing stable tree for some arches

[Duncan]

Pacho Ramos posted on Mon, 16 Feb 2015 14:34:50 +0100 as excerpted:

> The current policy of maintainers dropping keywords after 90 days is
> simply not applied because it leads up to that maintainer needing to
> kill himself that keyword and ALL the reverse deps keywords and, then,
> all that effort should probably be replaced by making the opposite, I
> mean, reducing the stable tree of that arches to a minimum and moving
> all the other packages to testing. The main advantage of this is that it
> needs maybe more effort in one round but it solves the problem for the
> future. On the other hand trying to kill keywords of a package *and all
> its reverse deps* requires a lot of work every time the problem appears.

Perhaps my non-dev status prevents me from understanding the difficulty 
here, but...  I really don't see the problem.

1) I don't believe the 90-day policy was /supposed/ to be particularly 
easy.  It was supposed to be a pressure relief valve, to release pressure 
only if it built up beyond a certain level, such that both archs and 
package-devs could still live with the situation by keeping the pressure 
from going off the scale at either location.

As a pressure reliever, what you defined as a bug I'd rather define as a 
feature.  If the situation gets bad enough and the pressure high enough, 
there's an approved method to relieve it, but that method itself isn't 
entirely pain-free, so it doesn't tend to be used until the pain of not 
using it is worse than the pain of using it, which, I'd argue, is 
functioning as intended.

2) The very requirement of having to kill ALL the reverse-deps seems to 
me to already lessen the pressure necessary to tip the balance the next 
time, since either it's not the problem its made out to be if it's only a 
handful of packages, or within a few cycles of doing this, there will be 
dramatically fewer packages keyworded in the first place to worry about, 
and thus dramatically fewer packages to have to dekeyword this time 
around.

Yes, the first time's going to be hell.  And the second time could easily 
be 90-95% as bad, particularly if the two packages are in separate areas 
and there's little overlap.  But the tenth?  By then, the number of 
packages still keyworded in the first place should be down enough to make 
a difference.  And the 20th?  By then, things should be much more 
reasonable.


So you're suggesting a flag day and volunteering to do most of the work.  
I won't argue with that as I don't have a dog in this fight.  But it 
seems to me, by the time you do even say five existing 90-day-
dekeywording-policy actions, you'll either have something already looking 
a lot more like the goal you outline above than the current state and 
will be well on your way, or if that DIDN'T dekeyword enough packages to 
already be easier, then by definition there's only a handful of such 
dependencies in the first place.

Either way, I simply don't see the problem, certainly so when comparing 
the work of just doing it under the existing policy, to fighting the 
political war necessary to change it -- and even assuming a win, ending 
up dekeywording pretty much the same set of packages as you'd have done 
with a few rounds under the existing policy anyway.

Again, not that I disagree.  As I said, no dog in this fight and I might 
actually benefit by the developer time then freed up to work on fights I 
do have a dog in.  But I expect this question will come up in some form 
in any case, and by answering it now, it'll already be dealt with.

Plus, I'm simply curious, as there's evidently an angle I'm blind to, and 
now being aware of that blindness, it's disturbing enough to me that I 
want to be rid of it, thus the question. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: About reducing or even removing stable tree for some arches

[Pacho Ramos]

El mié, 18-02-2015 a las 03:11 +0000, Duncan escribió:
> Pacho Ramos posted on Mon, 16 Feb 2015 14:34:50 +0100 as excerpted:
> 
> > The current policy of maintainers dropping keywords after 90 days is
> > simply not applied because it leads up to that maintainer needing to
> > kill himself that keyword and ALL the reverse deps keywords and, then,
> > all that effort should probably be replaced by making the opposite, I
> > mean, reducing the stable tree of that arches to a minimum and moving
> > all the other packages to testing. The main advantage of this is that it
> > needs maybe more effort in one round but it solves the problem for the
> > future. On the other hand trying to kill keywords of a package *and all
> > its reverse deps* requires a lot of work every time the problem appears.
> 
> Perhaps my non-dev status prevents me from understanding the difficulty 
> here, but...  I really don't see the problem.

Maybe that explains it, I have personally suffered it when we needed to
dekeyword most gnome stuff on all arches but amd64/x86 and even months
later we were still needing to remember to either keep moving to testing
other packages or finally postponing the move to testing for some and
try to stabilize some again (as the chain of reverse dep kept growing
forever).

I don't want to have to repeat that for every package that is not
attended in 90 days, and seeing that the arch teams that are unable to
stabilize/keyword things are, consequently, also unable to make this
huge work, the 90 days policy isn't going to start working any time soon
(it has never worked indeed as nobody wants to do the manual job of
checking all the reverse deps, move that deps to testing, recheck for
the reverse deps of those, and repeat and repeat).