On Jan 9, 2008 12:27 PM, Jesse Keating <jkeating@xxxxxxxxxx> wrote: > And if we had chosen that, it likely still wouldn't be where it is > today, because it wouldn't have had the exposure. It was functional > for the vast majority of uses and the exposure got more and more things > fixed on it. If there was an alternative then everybody would just > switch back to the old method, and no bugs would get filed and no > corner cases would get discovered. We need to build an accurate perception as to what we are offering in our releases. When we have the manpower to support it we drive technologies forward aggressively. We need to build the perception that our releases aren't just consumables, but they instead collaborative partnerships will our users to meet the goals of driving long term value into the open source software stack. We need to build the perception that when you choose to use fedora, you are choosing to be a part of the collaboration, and not just taking a product off the shelf giving it a spin. In areas where we have Fedora contributors who are active upstream developers, we tend to make integration decisions in release N which have the best potential for long term benefit for release N+1, N+2 and out into the future (especially in the area of hardware interaction). We know our process is not regression intolerant. But our process accommodates that fact by having an aggressive update process so people suffering hardware regressions can obtain fixes in a responsive manner. This isn't a policy, or a set of rules, this is how our development culture operates in broad brush strokes. It would be deeply disruptive to the project to attempt to suppress this essential nature. So how do we fix the perception that this is a bad thing? How do we attract users and contributors who are comfortable with some level of regression, for the sake of long term benefit? Naively, I would suggest continuing to enhance our Feature-scoping so that it includes known or suspected regression areas. And we need to be able to have our developers who are aggressively driving new technologies into our releases, make public commitments that they will work to address regressions as part of the update process. We can't make guarantees, but we can certainly project a perception that our developers care about hardware regressions and are willing to work with people to fix them. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
