Proposal - "Slow updates" repo
 

There's been a lot of talk about a stable release lately. Most agree
that its not what Fedora does best and not something that would be
natural for us to do. I have a sort of middle-ground proposal that might
be easy enough to implement that we could try it out.


Currently, when a packager has an update, he runs "make update," and
bodhi goes and grabs the package out of koji and places it in the next
mash of the updates-testing repo (Luke, please shout when I start
getting this wrong). Then, bold subscribers to updates-testing install
it, check it out, and if two people report in that it didn't eat their
brane, it goes into the regular updates repo. That slim sanity check
prevents a whole helluva lot of breakage, but isn't a very broad testing
of the package.


What I propose is having another repo called updates-slow. Like updates
testing this repo ships with Fedora but is disabled and hidden by
default. Interested parties would have to manually enable it, and
disable the regular updates repo. updates-slow would relate to updates
in a similar way that updates relates to updates-testing: packages would
go into it after people getting the general Fedora updates seem to be
ok. The criteria here would have to be much harder than the two karma
points it takes to move out of testing, I would suggest the people
interested in this feature form a group that decides what the entry
policy should be.


The advantage is that this is fairly cheap to set up. Bodhi would need
some level of changes (Luke, what do you think?) but there's no
branching. We're basically just taking the ability which already exists
in yum to selectively take updates and providing a system to
collaboratively exploit this mechanism.


Not branching, however, also creates a disadvantage: with no ability to
create new packages, the slow repo can't take newer fixes without taking
an entire update. The slow repo must consume updates from Fedora in
whole packages; they don't have patch-level control over incoming
changes. Also, the slow repo has to synchronize at release time; you
can't have a late-F9-with-bits-of-F10 offering (hopefully though the
base set is the peak of mainline Fedora's QA).


If the people interested in a stability feature are willing to help
govern and maintain this repo, and help with the bug load (we can't just
dump bugs against backdated versions directly on the maintainers), then
it could go a long way to meeting their needs.


Thoughts?

--CJD

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

Casey Dahlin wrote:
There's been a lot of talk about a stable release lately. Most agree
that its not what Fedora does best and not something that would be
natural for us to do. I have a sort of middle-ground proposal that might
be easy enough to implement that we could try it out.


Currently, when a packager has an update, he runs "make update," and
bodhi goes and grabs the package out of koji and places it in the next
mash of the updates-testing repo (Luke, please shout when I start
getting this wrong). Then, bold subscribers to updates-testing install
it, check it out, and if two people report in that it didn't eat their
brane, it goes into the regular updates repo. That slim sanity check
prevents a whole helluva lot of breakage, but isn't a very broad testing
of the package.


What I propose is having another repo called updates-slow. Like updates
testing this repo ships with Fedora but is disabled and hidden by
default. Interested parties would have to manually enable it, and
disable the regular updates repo. updates-slow would relate to updates
in a similar way that updates relates to updates-testing: packages would
go into it after people getting the general Fedora updates seem to be
ok. The criteria here would have to be much harder than the two karma
points it takes to move out of testing, I would suggest the people
interested in this feature form a group that decides what the entry
policy should be.


The advantage is that this is fairly cheap to set up. Bodhi would need
some level of changes (Luke, what do you think?) but there's no
branching. We're basically just taking the ability which already exists
in yum to selectively take updates and providing a system to
collaboratively exploit this mechanism.


Not branching, however, also creates a disadvantage: with no ability to
create new packages, the slow repo can't take newer fixes without taking
an entire update. The slow repo must consume updates from Fedora in
whole packages; they don't have patch-level control over incoming
changes. Also, the slow repo has to synchronize at release time; you
can't have a late-F9-with-bits-of-F10 offering (hopefully though the
base set is the peak of mainline Fedora's QA).


If the people interested in a stability feature are willing to help
govern and maintain this repo, and help with the bug load (we can't just
dump bugs against backdated versions directly on the maintainers), then
it could go a long way to meeting their needs.


Thoughts?


This almost runs into EPEL's agenda, and on the flip side there are people
that would like to see EPEL's updates come in a little more frequently.
Perhaps this 3-repo structure would work well for both groups ("testing",
"normal", "stable").


-Doug


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Casey Dahlin schrieb:
> There's been a lot of talk about a stable release lately. Most agree
> that its not what Fedora does best and not something that would be
> natural for us to do. I have a sort of middle-ground proposal that
> might be easy enough to implement that we could try it out.
I see the following issue:

If a maintainer publish a security update, which depends of one of the
package which are in the 'slow updates' repository, how do you want to
handle this case?

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkjECgACgkQT2AHK6txfgylDwCgugxmoct+pW 6KQA002R2Hpt2q
Y/sAoMlMYSAreaaw4X6NLtTJXIDc2Woj
=AdjS
-----END PGP SIGNATURE-----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

Jochen Schmitt wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Casey Dahlin schrieb:


There's been a lot of talk about a stable release lately. Most agree
that its not what Fedora does best and not something that would be
natural for us to do. I have a sort of middle-ground proposal that
might be easy enough to implement that we could try it out.


I see the following issue:

If a maintainer publish a security update, which depends of one of the
package which are in the 'slow updates' repository, how do you want to
handle this case?




This is the one drawback to this strategy. Here a human judgement call
would have to be made: Take the package and all its deps or run the
risk. The right answer would depend on the case, and on what the stable
group decides their use case is best served by.


--CJD


Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkjECgACgkQT2AHK6txfgylDwCgugxmoct+pW 6KQA002R2Hpt2q
Y/sAoMlMYSAreaaw4X6NLtTJXIDc2Woj
=AdjS
-----END PGP SIGNATURE-----




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

On Tue, Nov 18, 2008 at 10:02 AM, Casey Dahlin <cdahlin@redhat.com> wrote:
> This is the one drawback to this strategy. Here a human judgement call would
> have to be made: Take the package and all its deps or run the risk. The
> right answer would depend on the case, and on what the stable group decides
> their use case is best served by.

Security updates break the model for testing to. This is a known problem space.

If you take your idea...but also make it so client side users can
specifically know what is tagged as security and what is
not...regardless of repo "speed" then you probably have something
robust enough for everyone.

Give client side the option to pull ALL security updates...from any
repo "speed." That way the "slow" update repo doesn't have to be
burdened with dealing with security updates as part of their mission
as a special case.

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

Jeff Spaleta wrote:

On Tue, Nov 18, 2008 at 10:02 AM, Casey Dahlin <cdahlin@redhat.com> wrote:


This is the one drawback to this strategy. Here a human judgement call would
have to be made: Take the package and all its deps or run the risk. The
right answer would depend on the case, and on what the stable group decides
their use case is best served by.



Security updates break the model for testing to. This is a known problem space.

If you take your idea...but also make it so client side users can
specifically know what is tagged as security and what is
not...regardless of repo "speed" then you probably have something
robust enough for everyone.

Give client side the option to pull ALL security updates...from any
repo "speed." That way the "slow" update repo doesn't have to be
burdened with dealing with security updates as part of their mission
as a special case.

-jef



Not a bad idea.

--CJD

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

On Tue, 18 Nov 2008, Casey Dahlin wrote:


Jeff Spaleta wrote:

On Tue, Nov 18, 2008 at 10:02 AM, Casey Dahlin <cdahlin@redhat.com> wrote:

This is the one drawback to this strategy. Here a human judgement call
would

have to be made: Take the package and all its deps or run the risk. The
right answer would depend on the case, and on what the stable group
decides

their use case is best served by.



Security updates break the model for testing to. This is a known problem
space.


If you take your idea...but also make it so client side users can
specifically know what is tagged as security and what is
not...regardless of repo "speed" then you probably have something
robust enough for everyone.

Give client side the option to pull ALL security updates...from any
repo "speed." That way the "slow" update repo doesn't have to be
burdened with dealing with security updates as part of their mission
as a special case.

-jef



Not a bad idea.


you mean like the already existing yum security plugin and the update info
that bodhi generates?


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

2008/11/18 Seth Vidal <skvidal@fedoraproject.org>:
>
>
> On Tue, 18 Nov 2008, Casey Dahlin wrote:
>
>> Jeff Spaleta wrote:
>>>
>>> On Tue, Nov 18, 2008 at 10:02 AM, Casey Dahlin <cdahlin@redhat.com>
>>> wrote:
>>>
>>>> This is the one drawback to this strategy. Here a human judgement call
>>>> would
>>>> have to be made: Take the package and all its deps or run the risk. The
>>>> right answer would depend on the case, and on what the stable group
>>>> decides
>>>> their use case is best served by.
>>>>
>>>
>>> Security updates break the model for testing to. This is a known problem
>>> space.
>>>
>>> If you take your idea...but also make it so client side users can
>>> specifically know what is tagged as security and what is
>>> not...regardless of repo "speed" then you probably have something
>>> robust enough for everyone.
>>>
>>> Give client side the option to pull ALL security updates...from any
>>> repo "speed." That way the "slow" update repo doesn't have to be
>>> burdened with dealing with security updates as part of their mission
>>> as a special case.
>>>
>>> -jef
>>>
>>>
>> Not a bad idea.
>
> you mean like the already existing yum security plugin and the update info
> that bodhi generates?
>
> -sv
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-


maybe these 2 threads should be merged:
1. F11 Proposal: Stabilization
2. Proposal - "Slow updates" repo

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

On Tue, Nov 18, 2008 at 10:11 AM, Casey Dahlin <cdahlin@redhat.com> wrote:
> Not a bad idea.

I've reach my "not crap" idea quota for today. Everyone can now
safely ignore the remaining 300 posts I'm contracted to make to earn
my "stay at home at earn up to $1 an hour" income.

But as seth points out..before I could write a new email.... there is
some client side tooling in place to deal with security tagged updates
specifically. Now to support what you are talking about they may need
to be modified to support the usage case of "Slow updates except for
Security updates which I want as soon as possible".


-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Proposal - "Slow updates" repo
 

On Tuesday 18 November 2008 18:53:37 Casey Dahlin wrote:
> Currently, when a packager has an update, he runs "make update," and
> bodhi goes and grabs the package out of koji and places it in the next
> mash of the updates-testing repo (Luke, please shout when I start
> getting this wrong).

IIRC you must explicitly require a push to testing-updates. The upgrade is not
automatic.
--
José Abílio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list