FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-04-2010, 07:59 PM
Doug Ledford
 
Default To semi-rolling or not to semi-rolling, that is the question...

Obviously, some people want this and some don't. It isn't appropriate
to simply hand down an edict that things will be one way or the other if
we truly consider Fedora a community run project. It must be a
community decision. That means, as Adam Williamson pointed out, this is
likely a decision to be made by the board, based upon what the community
wants and what's best for Fedora.

But let's be clear. That's a *policy* decision. One of the things that
got very confusing in the previous thread(s) was the intermixing of
policy decisions and technical issues. For instance, Kevin's response
to my proposal was all about technical issues he saw. Technical issues
are almost always solvable if you have a specific policy you are trying
to implement. So one thing I think people should keep in mind is that
policy decisions should always lead to technical decisions, *not* the
other way around. We should decide what we want ourselves to be and
what our policies are, and then that should guide our infrastructure,
our tools, our work flows, and our processes. We should never allow
things to flow in the reverse direction. We should never allow a
current tooling limitation to set our policy, modulo that our policy
should acknowledge and accommodate for the time necessary for tooling
changes to take place or for the limitations of our resources.

So, I'm going to reiterate my policy suggestion:

Make Fedora releases (all of them) stable in nature, not semi-rolling.
Make rawhide consumable as a semi-rolling release itself.

Reasons:

1) Most importantly, it's a means of satisfying both groups of people in
the Fedora developer community and leaving none behind.
2) It saves developers time and effort. This is actually the least
burdensome method of satisfying both groups of people inside Fedora.
The whole 2 update stream approach increases the load on maintainers,
while this approach reduces the load on maintainers as a maintainer gets
to consider a Fedora release "done" when it goes out the door with the
exception of fixing any security or important bugs in that release. For
many packages, this means the maintainer will actually not have anything
to do in those releases and they can concentrate solely on devel (this
is obviously not true for big and highly used packages like thunderbird,
firefox, gnome, kde, they will always have bugs and updates needed, but
many other packages, especially smaller leaf packages, may never need a
single update during a stable release lifetime).
3) It conserves resources (drastically so) on the fedora infrastructure
and mirrors and reduces bandwidth needs greatly.
4) It helps Fedora scale (from a repo resource consumption standpoint at
least, but also in terms of developer time for the packages that won't
need lots of stable updates).
5) It would be less labor intensive to implement and work flows would be
simpler than the two update stream, ala Mandriva, approach to satisfying
everyone.

Before I get into the technical implementation part of the proposal, I
want to take a moment to step back and mention something to both sides
of the camp that have been involved in this discussion so far:

We have established, beyond any doubt whatsoever, that there are users
of Fedora that expect, demand, and need a stable update stream.
Ignoring those user's needs by saying "why can't we just stay as we are"
is tantamount to blatantly ignoring their cries for change/help,
trivializing their issues, and pushing them aside as unimportant.

We have established, beyond any doubt whatsoever, that there are users
of Fedora that expect, demand, and use fedora *because* they get major
updates in the middle of a release. Ignoring these users needs by
saying "rawhide is ==> way" without first doing what is necessary to
make rawhide usable and consumable is tantamount to blatantly ignoring
the untenable nature of your suggestion, trivializing their wants and
issues, and pushing them aside as unimportant.

So maybe we can choose to put the rhetoric that has flung around in this
discussion down, stop trivializing our fellow Fedora community member's
issues, and work together. After all, that's what being part of a
community is all about. If we can agree on a policy that satisfies both
groups of people, then that can inform and guide our technical
implementation discussions, keeping in mind that a failure of the first
draft of the technical implementation is not grounds to throw out the
policy, merely grounds for more work on the technical implementation ;-)

Technical implementation proposal:

1) Make rawhide consumable.
A) Create rawhide-unstable. Any time a known disruptive change is
being worked on, it should be built here by the developer. In
addition, add rpmdiff checks to all builds from devel into
dist-rawhide and if any of certain rpmdiff checks trip positive,
move the package from rawhide to rawhide-unstable. Additional
checks can be added as AutoQA gets into full swing, and so we can
add more ways to catch breakage and move things to rawhide-unstable
as needed.
B) Non disruptive changes go into rawhide directly, and on a regular
basis we run a compose on the rawhide tree to create install
disks/images for use. I suggest once a week we recreate the
images.
C) On a regular basis, we have a flag day to move items from
rawhide-unstable to rawhide. I originally said as-needed in my
first proposal, but on more reflection I would like to suggest
we make this a regular scheduled event on a monthly basis. In
this way we have 6 regular rawhide-unstable==>rawhide checkpoints
between each release cycle, and we can make the last one or two
prior to the next fedora release do double duty as both the
normal checkpoint and the fedora alpha/beta freeze. This also has
the side benefit that people working on major changes, like say
anaconda install updates, have more points at which they can get
their code into a consumable segment of the repo and start getting
feedback.
D) Anyone who likes that rawhide allows them to develop directly
on their OS can simply enable the rawhide-unstable repo in their
yum configs. Like enabling updates on a regular release, it
would inherit from rawhide and also include all the distruptive
changes. This makes a system with rawhide-unstable enabled
identical to rawhide today.
E) Without rawhide-unstable, you get a semi-rolling release that
allows for regular checkpoints to introduce disruptive changes,
soname bumps, etc. only on a more frequent basis than the current
fedora release cycle. It is hoped that by having this higher
frequency, disruptive changes in the semi-rolling release that is
rawhide can be handled more easily. Kind of along the lines of
easier to deal with by taking more, smaller bites instead of huge,
hard to swallow bites.

2) Make Fedora releases adhere to a stable release policy. This already
covered rather well in proposals put forth by other people. Mike
McGrath's snapshot proposal and Matt Domsch's Slowing rate of change in
older releases proposal are the two I would pair with my proposal in
order to satisfy both groups. I don't see any reason to rehash them here.

--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 09:09 PM
Till Maas
 
Default To semi-rolling or not to semi-rolling, that is the question...

On Thu, Mar 04, 2010 at 03:59:16PM -0500, Doug Ledford wrote:

> But let's be clear. That's a *policy* decision. One of the things that
> got very confusing in the previous thread(s) was the intermixing of
> policy decisions and technical issues. For instance, Kevin's response

> So, I'm going to reiterate my policy suggestion:
>
> Make Fedora releases (all of them) stable in nature, not semi-rolling.
> Make rawhide consumable as a semi-rolling release itself.

Imho this semi-rolling is too blurry, because only the technical
implementation give a grasp of what is rolling.

I thought I was pro semi-rolling, but the technical proposal did not
seem to fit my expectation. Here is what I would like to have as
semi-rolling. What I would like to have semi rolling is as many updates
that fix known bugs, even if only upstream knows them, as long as they
fit these criteria:
http://lists.fedoraproject.org/pipermail/devel/2010-February/131570.html

And they must pass all AutoQA tests, which is not a big issue currently,
but will be if AutoQA becomes what I would like it to be.

All other updates should only be mandatory like every six to twelve months.
Also I would like to have packages that are required to fix broken
updates be taken a little bit more care of. Afaik this is what is
happening with the critical path nowadays.

These are my desires as mostly a user. As a packager I would like to
also have some staging instance (like updates-testing), where I can
stage updates that are supposed to match the criteria, but can be easily
used to verify this. So I can tell users to verify that a bug is fixed,
if there is no easy way to reproduce it myself, e.g. if it requires a
complex setup.

Since there also needs to be a repo where things can be arbitrarily
broken to develop fixes, to satisfy this semi rolling approach and the
stable one is to create two more repos per stable release, so we would
have these:
fedora - initial release
updates-testing - testing updates targeted at updates
updates - semi rolling wrt. to above policy outline
updates-stable-staging - used to test updates for updates-stable
updates-stable - only gets updates wrt. to a stable policy

To lower the demand of resources, the updates/updates-testing could not
be provided for the full lifetime of the release, but e.g. only for
around nine months. A Milestone could be the Alpha release of the
Rawhide branch of N+2, e.g.

F13 updates will be supported until F15 Alpha is created, so
everyone has a about a three month update window to get from FN-updates to
F(N+1)-updates or F(N+1)-updates-stable.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 10:23 PM
Petrus de Calguarium
 
Default To semi-rolling or not to semi-rolling, that is the question...

Doug Ledford wrote:

> [the whole nine yards]

I like this idea. As a user of fedora updates-
testing and kde-redhat, in order to get the
latest software the soonest onto my computer,
without having the burden of reinstalling my
system twice a year on 2 computers, x86_64
desktop and i686/PAE laptop, I like the idea of
being able to run rawhide perpetually (and not
having it get into such a conundrum that one day
it will no longer even boot, due to some bad yum
update). I had flippantly proposed 'fedora
infinity' a year or two back on this list and it
was shot down :-( I was told that I should look
into sidux or arch linux, I think. Sorry, I'm not
into building my system from scratch and
appreciate the fantastic work here and, were
rawhide to always work while always being on the
edge of the latest development, and no longer
having to reinstall twice a year, i.e., having
rawhide become a de facto rolling release, I
would be thrilled with it!!!


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 10:27 PM
Kevin Kofler
 
Default To semi-rolling or not to semi-rolling, that is the question...

Doug Ledford wrote:
> But let's be clear. That's a *policy* decision. One of the things that
> got very confusing in the previous thread(s) was the intermixing of
> policy decisions and technical issues. For instance, Kevin's response
> to my proposal was all about technical issues he saw. Technical issues
> are almost always solvable if you have a specific policy you are trying
> to implement. So one thing I think people should keep in mind is that
> policy decisions should always lead to technical decisions, *not* the
> other way around. We should decide what we want ourselves to be and
> what our policies are, and then that should guide our infrastructure,
> our tools, our work flows, and our processes. We should never allow
> things to flow in the reverse direction. We should never allow a
> current tooling limitation to set our policy, modulo that our policy
> should acknowledge and accommodate for the time necessary for tooling
> changes to take place or for the limitations of our resources.

I heavily disagree with that assertion. We need to always keep the technical
and practical limitations in mind when deciding on a policy. It doesn't make
sense to enact a policy which cannot be realized due to technical
limitations, or whose realization causes unsolvable problems. The technical
details are essential. Only a policy with a good technical implementation
can be a good policy.

I can set a policy that we should colonize Mars by 2011, people may love
that policy, but then they'll be really angry when either I have to tell
them that we have no way to actually do that, or I send people to Mars in
some crappy improvised equipment and they all die on the way. Heck, even if
the goal is technically "met" and some people arrive there alive, the policy
can still be a failure, e.g. if everyone dies within a week of arriving
because the oxygen supplies run out.

We need to make sure that whatever we decide is actually feasible, and
consider the technical limitations of the proposed implementation as an
integral part of the proposal. Explaining them away as "technical" won't
make them any less real.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 03:10 AM
Doug Ledford
 
Default To semi-rolling or not to semi-rolling, that is the question...

On 03/04/2010 06:27 PM, Kevin Kofler wrote:
> Doug Ledford wrote:
>> But let's be clear. That's a *policy* decision. One of the things that
>> got very confusing in the previous thread(s) was the intermixing of
>> policy decisions and technical issues. For instance, Kevin's response
>> to my proposal was all about technical issues he saw. Technical issues
>> are almost always solvable if you have a specific policy you are trying
>> to implement. So one thing I think people should keep in mind is that
>> policy decisions should always lead to technical decisions, *not* the
>> other way around. We should decide what we want ourselves to be and
>> what our policies are, and then that should guide our infrastructure,
>> our tools, our work flows, and our processes. We should never allow
>> things to flow in the reverse direction. We should never allow a
>> current tooling limitation to set our policy, modulo that our policy
>> should acknowledge and accommodate for the time necessary for tooling
>> changes to take place or for the limitations of our resources.
>
> I heavily disagree with that assertion. We need to always keep the technical
> and practical limitations in mind when deciding on a policy.

Limitations, yes. Current state, no. You can't make a policy to do the
impossible and expect it to just happen. But you *can* make a policy to
do the very hard and seemingly impossible and make it happen. To that
end I reference the fact that man has in fact been to the moon and it
was a policy mandate by two competing governments that caused us (as a
species) to do the work to get there. Deciding that a policy is good is
the first step to being willing to commit to the work to implement it.

> It doesn't make
> sense to enact a policy which cannot be realized due to technical
> limitations, or whose realization causes unsolvable problems. The technical
> details are essential.

You only need enough details to know that it isn't impossible, not
enough to know the exact route to get to the end goal.

> Only a policy with a good technical implementation
> can be a good policy.

In the end, this is true. In the beginning, it is not.

[ snip the remainder of your non-reply ]

Please, if you have objections to the policy, then state them. What I
got from your email is you objected to me saying set policy first,
technical implementation later, and then you never once said anything
about the policy nor the technical implementation. Should I then take
your silence on those issues to mean that you are OK with the policy and
OK with the proposed technical implementation?

--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 03:40 AM
Tom Lane
 
Default To semi-rolling or not to semi-rolling, that is the question...

Doug Ledford <dledford@redhat.com> writes:
> Limitations, yes. Current state, no. You can't make a policy to do the
> impossible and expect it to just happen. But you *can* make a policy to
> do the very hard and seemingly impossible and make it happen. To that
> end I reference the fact that man has in fact been to the moon and it
> was a policy mandate by two competing governments that caused us (as a
> species) to do the work to get there.

Correction: it was a policy mandate plus the expenditure of a lot of
billions of dollars that got us to the moon.

>> It doesn't make
>> sense to enact a policy which cannot be realized due to technical
>> limitations, or whose realization causes unsolvable problems. The technical
>> details are essential.

> You only need enough details to know that it isn't impossible, not
> enough to know the exact route to get to the end goal.

You also need the resources to make it happen. A mandate from FESCO
is not worth diddly-squat unless FESCO is prepared to do the work.

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 04:46 AM
Kevin Kofler
 
Default To semi-rolling or not to semi-rolling, that is the question...

Till Maas wrote:
> F13 updates will be supported until F15 Alpha is created, so
> everyone has a about a three month update window to get from FN-updates to
> F(N+1)-updates or F(N+1)-updates-stable.

FN-updates to F(N+1)-updates-stable is unlikely to work, because FN-updates
will be including stuff which is only in F(N+1)-updates, not F(N+1)-updates-
stable.

(And FWIW, I'd call them "conservative" rather than "stable", I don't like
the implication that the other stream would be "unstable", which to most
users means "crashy".)

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 06:52 AM
Hans de Goede
 
Default To semi-rolling or not to semi-rolling, that is the question...

Hi,

On 03/04/2010 09:59 PM, Doug Ledford wrote:
> Obviously, some people want this and some don't. It isn't appropriate
> to simply hand down an edict that things will be one way or the other if
> we truly consider Fedora a community run project. It must be a
> community decision. That means, as Adam Williamson pointed out, this is
> likely a decision to be made by the board, based upon what the community
> wants and what's best for Fedora.
>
> But let's be clear. That's a *policy* decision. One of the things that
> got very confusing in the previous thread(s) was the intermixing of
> policy decisions and technical issues. For instance, Kevin's response
> to my proposal was all about technical issues he saw. Technical issues
> are almost always solvable if you have a specific policy you are trying
> to implement. So one thing I think people should keep in mind is that
> policy decisions should always lead to technical decisions, *not* the
> other way around. We should decide what we want ourselves to be and
> what our policies are, and then that should guide our infrastructure,
> our tools, our work flows, and our processes. We should never allow
> things to flow in the reverse direction. We should never allow a
> current tooling limitation to set our policy, modulo that our policy
> should acknowledge and accommodate for the time necessary for tooling
> changes to take place or for the limitations of our resources.
>
> So, I'm going to reiterate my policy suggestion:
>
> Make Fedora releases (all of them) stable in nature, not semi-rolling.

One size does still not fit all, although this is a great idea for
most packages in Fedora for packages in certain niches this is a bad idea.

I've said this before (and got 0 response), I believe there should
be some divide made between core packages (with core being quite big, not
the bare essentials, but also most of all desktop environments, etc.) and
non core packages.

For example I really see no reason not to upgrade
some EDA tool to the latest and greatest if the maintainer thinks that
there are good reasons to do this, because the group of EDA users bitten by
potential regressions is small and EDA users are highly technical skilled,
so know how to downgrade if needed.

Another example is multiplayer games. In quite a few online gaming
communities, most of the community moves over to the latest release once it
is sanctioned stable by upstream. If the client <-> server version need to
be in sync (which they often do because they need the exact same maps),
then this means that our "stable" version in F-released might become
worthless pretty quickly as there are no or very little "stable" version
servers available to play on.

I strongly urge FESco to come up with a policy which is flexible enough to
handle these kind of special cases, without requiring going to rel-eng for
an exception each and every time. And to mandate that the tools are
flexible enough too.

Also I cannot get rid of the collective punishment feeling here, because
a few people do crazy things, ALL of us loose the right to apply common
sense and have to adhere to strict policy and jump to even more hoops to
get updates out there. How about a FAS flag which decides if a maintainer
can skip updates-testing, which default to yes, and take this away from
people who show to little restraint in skipping updates-testing ?

> Make rawhide consumable as a semi-rolling release itself.

We already have this it is called early branching of the next release. I
would fully agree with you if it were not for the early branching
feature, which means we effectively already have such a release, except
the first 2 months or so after a release, at which time rawhide
tends to be very volatile in general (*), so a stabilized rawhide would
pretty much boil down to the latest release anyways.

Given that we pretty much already have this my reaction to this is
please not another tree!

* (we still need to see if no frozen rawhide changes this)

Regards,

Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 08:11 AM
Kevin Kofler
 
Default To semi-rolling or not to semi-rolling, that is the question...

Doug Ledford wrote:
> You only need enough details to know that it isn't impossible, not
> enough to know the exact route to get to the end goal.

Only an actually working implementation, or a detailed technical description
of one, can prove that it really isn't impossible and doesn't lead to
unsurmountable technical difficulties that make it suck in practice.

> Please, if you have objections to the policy, then state them. What I
> got from your email is you objected to me saying set policy first,
> technical implementation later, and then you never once said anything
> about the policy nor the technical implementation. Should I then take
> your silence on those issues to mean that you are OK with the policy and
> OK with the proposed technical implementation?

I'm going to reply to your original message.

Kevin Kofler


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 08:38 AM
Till Maas
 
Default To semi-rolling or not to semi-rolling, that is the question...

On Fri, Mar 05, 2010 at 08:52:56AM +0100, Hans de Goede wrote:

> One size does still not fit all, although this is a great idea for
> most packages in Fedora for packages in certain niches this is a bad idea.
>
> I've said this before (and got 0 response), I believe there should
> be some divide made between core packages (with core being quite big, not
> the bare essentials, but also most of all desktop environments, etc.) and
> non core packages.

I kind of agree with you, but without completely describing these core
packages, it is kind of hard to know what to agree to. Imho it is not
only "core-ness", but also package complexity that should be taken into
account (and upstream QA, but you mentioned this in your other mail).
But as you wrote their, it mostly boils down to a maintainer decision
and cannot easily be written into a Policy, but more into a guideline
for maintainers to help them decide.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 10:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org