[snip] > > The other problem is that it continues to make Fedora as a project look > bad. I've talked to people who use Fedora (who aren't involved in the I disagree. It is far better to have the release slipped in order to fix blocker bugs. We have a nice QA and this improves the Fedora quality. Of course, this time it is an exception and don't have to be seen on an other way. That does not prevent us to work on a better release schedule of course, if we can find a better solution. > project in any form or fashion), and it's a rather annoying pain point that > they *don't know when to expect the next Fedora release*. The fact that Fedora is a leading GNU/Linux distribution. Lot of people are waiting for the last Fedora release to get the best of the Free and Open Source software. We are not a comercial product dealing with licence updates and other things. Lot of people love Fedora but don't like to update every year.. But they did. Because this is how we manage to lead the effort, to move forward. Sometimes, you hit a red light. This is where you can evaluate your community and see how strong you are to react, and see what decision you take. Changing the release cycle would take time and change the whole perspective. Moving back to the old Anaconda would take time. Every schedule change take time. What we actually need is to move forward as soon as possible, but smoothly. The real question is how can we (devs not yet anaconda contributors) help the Anaconda team if do-able, *now*. [snip] > Regardless of all that, we need to be better about communicating that we > use a feature-based release scheme as opposed to a time-based release > scheme. There are trade-offs to both approaches, but at least with clear > communication, we set the right expectations. I agree, communication helps to prevent many issues. -- Kévin Raymond (Shaiton)
Attachment:
pgpaGaS6AQ14g.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
