To semi-rolling or not to semi-rolling, that is the question...

[Doug Ledford]

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 at redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100305/fec811da/attachment.bin