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-05-2010, 09:07 PM
Doug Ledford
 
Default To semi-rolling or not to semi-rolling, that is the question...

On 03/05/2010 03:58 PM, Kevin Kofler wrote:
> Doug Ledford wrote:
>> It comes with less extra work than doing two update streams. Face it,
>> there is *no* solution to this problem that both solves the issue for
>> both parties involved and does not include at least *some* extra work
>> for you.
>
> Sure, but will yours be *less* extra work? And do we also really need to
> target both groups in the first place (as opposed to focusing on the fast-
> moving solution which distinguishes us from other distros), seeing how many
> existing distributions already fill the need for the conservative variant?
>
> [re users who expect a conservative update policy]
>> They are fedora users today, ignoring them is exceedingly rude.
>
> It was their choice to use Fedora. They may have made the wrong choice, but
> that doesn't mean they get to turn Fedora into something different. As an
> analogy, if I walk into a gay bar, I don't get to convert it into a bar for
> heterosexuals just because I happen not to be attracted by men.

Your analogy falls very far from the truth of the situation. Many of
the people that have expressed this desire ran Fedora back in the days
before it was merged, and in those days Fedora Core did in fact have the
more conservative update style as a general rule. So it's not as though
they walked into a bar and tried to change it, the bar changed out from
underneath them. What's more, it's not like the bar is even gay or
hetero right now, it's a mix of both.

Regardless, I think I can sum up our two positions on this without
needing to to rehash your entire email.

I think a rolling rawhide could be done, but it would require more work
than it takes today, and in so doing we could satisfy both user groups.
I'm willing to do my part and commit to that work (which is all that's
really required to solve your claims that people will leave things in
rawhide-unstable and they will diverge...if people commit to taking care
of *finishing* projects they start in rawhide-unstable, it will not
diverge over time but will instead remain very close to rawhide).

You think any sort of rolling-rawhide is a lost cause, and you
personally couldn't care less about the group that wants a more
stable/conservative update stream in released products, so you would
rather save the extra work that *any* solution would entail and tell the
other group of people "So long, don't let the door hit you on the way
out". To that end, you will use what amounts to fatalism as a basis for
objecting to the technical merits of any proposed solution (aka, it's
not that what I proposed can't work, just that you think it won't
because you and people like you won't participate and it will therefore
fail).

So, really, I don't see the point in arguing this further with you. I
already know what your responses will be, and they aren't particularly
enlightening to the discussion (although you *might* be correct on how
things would turn out in the end, there is by no means a certainty that
everyone else will display the same refusal to even try to make these
changes work that you are displaying, and that in and of itself would be
a major factor in whether or not my suggestion had any chance of success).

>> And given the fact that more people have stood up requesting a more stable
>> update stream than those that have stood up for the semi-rolling update
>> stream,
>
> Really? That's not the impression I got.

Reread the thread and do a count.

>> My proposal *is* trying to do that. Whether or not it is a lost cause
>> is a function of *us*. We make rawhide consumable, or we make it a
>> minefield. Either way, it's our actions at work. All we have to do is
>> care.
>
> No matter what we do, we can't achieve the impossible.

See, fatalism. I snipped the remainder of your email. As you said, you
got my points. I get your points. I just simply disagree on two issues:

1) that we should ignore the other group you think we should ignore
2) that an attempt to solve the problem is doomed to failure (and the
majority of your technical objections all really revolve around this
point, not real actual technical problems)


--
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, 10:00 PM
Kevin Kofler
 
Default To semi-rolling or not to semi-rolling, that is the question...

Doug Ledford wrote:
> and in those days Fedora Core did in fact have the more conservative
> update style as a general rule.

Oh really?

http://lists.fedoraproject.org/pipermail/announce/2005-December/thread.html#1678
| Fedora Core 4 Update: arts-1.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdelibs-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdebase-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeaccessibility-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeaddons-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeadmin-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeartwork-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdebindings-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeedu-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdegames-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdegraphics-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdemultimedia-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdenetwork-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdepim-3.5.0-0.2.fc4 Than Ngo
| Fedora Core 4 Update: kdesdk-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeutils-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdevelop-3.3.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdewebdev-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kde-i18n-3.5.0-0.1.fc4 Than Ngo

That's KDE 3.5.0 for Fedora Core 4, which shipped with KDE 3.4.0. It got
subsequently updated to 3.4.1:
http://lists.fedoraproject.org/pipermail/announce/2005-June/thread.html#950
3.4.2:
http://lists.fedoraproject.org/pipermail/announce/2005-July/thread.html#1164
3.5.0 (a feature release!):
http://lists.fedoraproject.org/pipermail/announce/2005-December/thread.html#1678
3.5.1:
http://lists.fedoraproject.org/pipermail/announce/2006-February/thread.html#1784
3.5.2:
http://lists.fedoraproject.org/pipermail/announce/2006-April/thread.html#2068
and finally 3.5.3:
http://lists.fedoraproject.org/pipermail/package-announce/2006-June/thread.html#252
at which point Fedora Core 4 reached its end of life.

How's that different from what we're doing now?

> I think a rolling rawhide could be done, but it would require more work
> than it takes today, and in so doing we could satisfy both user groups.
> I'm willing to do my part and commit to that work (which is all that's
> really required to solve your claims that people will leave things in
> rawhide-unstable and they will diverge...if people commit to taking care
> of *finishing* projects they start in rawhide-unstable, it will not
> diverge over time but will instead remain very close to rawhide).

The problem is that you want to conduct your experiments at the expense of
our existing userbase. Those users (including me) are less than thrilled
about being the guinea pigs for your experiments which even you aren't sure
will work out.

> You think any sort of rolling-rawhide is a lost cause, and you
> personally couldn't care less about the group that wants a more
> stable/conservative update stream in released products, so you would
> rather save the extra work that *any* solution would entail and tell the
> other group of people "So long, don't let the door hit you on the way
> out". To that end, you will use what amounts to fatalism as a basis for
> objecting to the technical merits of any proposed solution (aka, it's
> not that what I proposed can't work, just that you think it won't
> because you and people like you won't participate and it will therefore
> fail).

You call it fatalism, I call it realism.

Kevin Kofler

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

Hi,

On 03/05/2010 06:56 PM, Doug Ledford wrote:
> On 03/05/2010 02:52 AM, 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.
>
> Well, the reason I didn't respond before is because I thought I had no
> disagreement with what you wrote. It seems obvious to me that even if
> we made a policy that Fedora was primarily stable once released, that
> there would always be exceptions to that rule and things that should be
> updated more aggressively. So I would not advocate for any policy that
> was absolute and inflexible. There should be room for human judgment to
> play a role.
>

Ok I'm very happy to hear that, and hope this will be clearly reflected
in the final policy for this,

Regards,

Hans



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

Hi,

On 03/05/2010 06:32 PM, Toshio Kuratomi wrote:
> On Fri, Mar 05, 2010 at 08:52:56AM +0100, Hans de Goede wrote:
>>> 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.
>>
> This is something I've been toying with in my mind myself. I like the idea
> of using it better than using rawhide for the same reasons that Till Mass
> mentions in his email. I haven't been able to completely satisfy myself on
> two points though:
>
> 1) This new tree is supposedly leading towards a new release. As such,
> there are other pressures on it than simply being a consumable tree. (For
> instance, updates will be frozen for periods in this tree as alpha and beta
> are spun; the freezes lead to a huge number of updates on release day). How
> disruptive these pieces are to using this tree as a consumable product in
> its own right is the worry. However, we haven't yet run a full release of
> no-frozen-rawhide so we don't know precisely how annoying the problems would
> be or how easily solvable.
>

Yes it will be frozen every now and then, so it is semi rolling not continously
rolling. So people who want something between stable and semi -rolling could even
only update at moments when the tree is frozen (and thus known to be relatively
problem free).

> 2) The new tree is not consumable all the time because there are times when
> it does not exist. As you also mention, there is the period right after
> release when the unrelease tree does not exist. There's only F-current
> (which would be taking less updates under a policy that anticipates people
> who want semi-rolling to be consuming the F-current+1 tree) and rawhide
> (which, as you say, is very volatile at this time.) In fact, this is
> probably the time period in which a semi-rolling tree would be most useful
> to people (as at other times of the cycle, maintainer laziness would make
> rawhide closer to the current+1 tree and therefore more consumable) Do you
> have any ideas on what we could do here?
>

Well again I think that a 1 - 2 month window without exciting updates is
quite ok for people who want semi-rolling.

I agree that both issues you mention are not ideal, but IMHO they
are something we can live with, where as the burden of yet another tree
is not something we can live with.

Regards,

Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 12:00 AM
Jesse Keating
 
Default To semi-rolling or not to semi-rolling, that is the question...

On Thu, 2010-03-04 at 15:59 -0500, Doug Ledford wrote:
> 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.

Slight variation on this. All builds from devel/ (or master in the new
git world) would go to the koji tag dist-rawhide-candidate. Builds
which are tagged with dist-rawhide-candidate trigger AutoQA tests, of
the nature "rawhide acceptance" (this would have to get fleshed out at
some point, but it'd be something that builds upon the tests we would
already do post-build). Builds that pass rawhide acceptance would get
tagged into dist-rawhide, would show up in the build roots, and would be
part of the nightly rawhide compose. Builds that do not remain in
dist-rawhide-candidate. A maintainer can review the failed cases and
make a decision, override the system or do a new build. Egregious use
of system overriding would trigger FESCo attention and perhaps some sort
of retraining or sanctioning.


> 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.

I'd leave the install images creation out of this for now, that's
primarily a decision for the anaconda developers to make, as to when
they wish to have mirrored install images created and used for bug
reporting.

> 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.

That's an interesting thought, coordinated moves from either untagged or
dist-rawhide-candidate over to dist-rawhide.

> 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.

I think we could accomplish this with a simple koji static repo. It's
far cheaper than trying to do a full multilib mashed repo every night of
this content, and it gets updated far more frequently.

> 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.

I think there is room to do soname changes more frequently than the
scheduled disruption days, provided that all in Fedora consumers of a
soname are bumped at the same, or at least moved into -rawhide at the
same time. This would require a higher level of coordination, and more
specific koji buildroots. A tax on the system, to be sure.

>
> 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.
--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 03:45 PM
Kevin Kofler
 
Default To semi-rolling or not to semi-rolling, that is the question...

Jesse Keating wrote:
> Slight variation on this. All builds from devel/ (or master in the new
> git world) would go to the koji tag dist-rawhide-candidate. Builds
> which are tagged with dist-rawhide-candidate trigger AutoQA tests, of
> the nature "rawhide acceptance" (this would have to get fleshed out at
> some point, but it'd be something that builds upon the tests we would
> already do post-build). Builds that pass rawhide acceptance would get
> tagged into dist-rawhide, would show up in the build roots, and would be
> part of the nightly rawhide compose. Builds that do not remain in
> dist-rawhide-candidate. A maintainer can review the failed cases and
> make a decision, override the system or do a new build. Egregious use
> of system overriding would trigger FESCo attention and perhaps some sort
> of retraining or sanctioning.

The assumption is that automated QA catches all possible breakage, which is
not true. In fact *no* QA will catch all the Rawhide breakage as some is
caused by the mere fact of things being different, which is intentional and
part of what Rawhide is about (e.g. the libata change in the kernel, the
change from KDE 3 to 4 etc.). Releases are needed to handle this kind of
changes in a smooth way. But automated QA will also miss many actual bugs.

Kevin Kofler

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

On Tue, 2010-03-09 at 17:45 +0100, Kevin Kofler wrote:
> The assumption is that automated QA catches all possible breakage, which is
> not true. In fact *no* QA will catch all the Rawhide breakage as some is
> caused by the mere fact of things being different, which is intentional and
> part of what Rawhide is about (e.g. the libata change in the kernel, the
> change from KDE 3 to 4 etc.). Releases are needed to handle this kind of
> changes in a smooth way. But automated QA will also miss many actual bugs.

Yes, you bear some risk in using rawhide. There is no reward without
risk. We can mitigate some of that risk by placing automated testing
between the builds and the users. Some reduction in risk is far better
than no reduction is it not? Would it not be nice to see rawhide
reports without the huge list of broken deps? Would it not be nice to
have a rawhide build update that doesn't segfault upon execution? These
are the kinds of things that happen now, that AutoQA could prevent.
That makes rawhide vastly more consumable than it currently is.

Perfect is the enemy of good.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 05:39 PM
Kevin Kofler
 
Default To semi-rolling or not to semi-rolling, that is the question...

Jesse Keating wrote:
> Yes, you bear some risk in using rawhide. There is no reward without
> risk. We can mitigate some of that risk by placing automated testing
> between the builds and the users. Some reduction in risk is far better
> than no reduction is it not? Would it not be nice to see rawhide
> reports without the huge list of broken deps? Would it not be nice to
> have a rawhide build update that doesn't segfault upon execution? These
> are the kinds of things that happen now, that AutoQA could prevent.
> That makes rawhide vastly more consumable than it currently is.

But it is no replacement for the current non-conservative updates to
releases, whereas the OP's proposal wants to drop those in favor of the
"consumable" Rawhide.

Kevin Kofler

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

On Tue, 2010-03-09 at 19:39 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> > Yes, you bear some risk in using rawhide. There is no reward without
> > risk. We can mitigate some of that risk by placing automated testing
> > between the builds and the users. Some reduction in risk is far better
> > than no reduction is it not? Would it not be nice to see rawhide
> > reports without the huge list of broken deps? Would it not be nice to
> > have a rawhide build update that doesn't segfault upon execution? These
> > are the kinds of things that happen now, that AutoQA could prevent.
> > That makes rawhide vastly more consumable than it currently is.
>
> But it is no replacement for the current non-conservative updates to
> releases, whereas the OP's proposal wants to drop those in favor of the
> "consumable" Rawhide.
>

Somebody is going to have to pay the price. Either users on our
released Fedoras will have to pay the price of potentially unstable
updates coming at them, changing behavior and adding regressions, or the
users who want those kind of updates will have to pay the price of other
potentially unstable updates coming along too, changing behavior and
adding regressions. The question is who gets to suffer? Right now,
everybody is.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:06 PM
Doug Ledford
 
Default To semi-rolling or not to semi-rolling, that is the question...

On 03/09/2010 11:45 AM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> Slight variation on this. All builds from devel/ (or master in the new
>> git world) would go to the koji tag dist-rawhide-candidate. Builds
>> which are tagged with dist-rawhide-candidate trigger AutoQA tests, of
>> the nature "rawhide acceptance" (this would have to get fleshed out at
>> some point, but it'd be something that builds upon the tests we would
>> already do post-build). Builds that pass rawhide acceptance would get
>> tagged into dist-rawhide, would show up in the build roots, and would be
>> part of the nightly rawhide compose. Builds that do not remain in
>> dist-rawhide-candidate. A maintainer can review the failed cases and
>> make a decision, override the system or do a new build. Egregious use
>> of system overriding would trigger FESCo attention and perhaps some sort
>> of retraining or sanctioning.
>
> The assumption is that automated QA catches all possible breakage, which is
> not true. In fact *no* QA will catch all the Rawhide breakage as some is
> caused by the mere fact of things being different, which is intentional and
> part of what Rawhide is about (e.g. the libata change in the kernel, the
> change from KDE 3 to 4 etc.). Releases are needed to handle this kind of
> changes in a smooth way. But automated QA will also miss many actual bugs.

Things like the libata kernel change and KDE 3 to 4 migration are
intentional events and all that's needed to make the transition smooth
is to coordinate the release of a seamless upgrade package set. You
make it sound like these things are impossible when nothing could be
further from the truth. And it's expected that a responsible maintainer
is aware of these sorts of intentional update events and all that needs
to be done is for them to conscientiously build their packages into the
rawhide-candidate dist repo and coordinate a release of a complete set
of packages. Automated QA need not catch this type of event.

And automated QA *will* catch many more bugs than it misses (speaking
from the mouth of experience knowing all the automated QA checks my rhel
packages must pass prior to each update), and there was never an
assumption that it would catch *all* issues. In fact the suggestion
that automated QA would need to catch *all* issues before the proposal
meets your approval makes it very apparent how disingenuous your stance
on this proposal is.

FACT: the semi-rolling update model you so love today is not foolproof
and does not keep users from experiencing periodic, occasional breakage
(see KDE update thread).
FACT: you are strongly in support of the current semi-rolling model that
you practice today (see multiple threads).
FACT: you have purported that even with things occasionally breaking as
they did on the recent KDE update, that these things are impossible to
prevent 100% and that the system is working "as designed" (see KDE thread).

So, for you to say this automated QA wouldn't catch *all* issues and
therefore this proposal is unworkable, and then on the other hand say
that major updates in RELEASED products that cause breakage are OK and
working "as designed" puts your hypocrisy very much in the spotlight.

A consumable rawhide need only meet the level that our released products
do today (a level that you personally have helped to drag down BTW) and
at that point you have *NO* valid grounds to object to it. And if we
made rawhide meet that level of consumability, we should at the same
time be *raising* the bar for our released products. Your argument
appears to be that since we can't make rawhide meet what should possibly
be the raised bar of the released products then the idea won't work so
lets lower the bar across the board and give up.

I'm sorry Kevin, but you and I will simply have to agree to disagree. I
will *not* capitulate to your stance on this issue.

--
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
 

Thread Tools




All times are GMT. The time now is 04:56 AM.

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