A slightly longer reply... John Poelstra (poelstra@xxxxxxxxxx) said: > schedules. I believe the Fedora project can scale successfully with > detailed schedules and more information about what happens in each step. Where are we failing to scale now? Is it (to use string freezes as an example): 1) people don't know about dates like string freezes (a schedule distribution issue) 2) people don't know what string freezes are (a terminology issue) 3) people don't care about string freezes (a management issue) 1) can be solved with more communication, and potentially with tools 2) can be solved with better documentation. 3) can't be solved with tools without going to extremely draconian measures that I don't feel are truly worth it. > As I went through the Fedora schedule here: > http://fedoraproject.org/wiki/Releases/7 I found a general outline of what > is supposed to happen, but not a lot of explanation about what each step > means or what is required for a particular milestone to be considered > finished... in other words, "what exactly does String Freeze mean?" This is the sort of doucmentation we should have for newer developers; for those that have been around long enough, this is sort of assumed knowledge. For example: - "Development freeze" The package set is frozen. Only packages that fix significant issues found in testing are added to the tree. - "Release" Availability for download. - "Feature freeze" All features must be complete in a testable state. Anything that's not will either be dropped or reverted. - "String freeze" Translatable Fedora-specific strings and user-interfaces should be frozen, to give the translators time to finish their work. - "Translation freeze" This is the last point for translations to be contributed and be guaranteed to get in the release. Any translations after this need to be officially requested to get pulled in. > The benefits of having the Fedora schedules in a project planning tool is > that it is easier to manage unforeseen delays, plan alternate scenarios, > and have a clearer sense of how we are doing at a particular point in time > towards meeting the published schedule on time. How does this do this in the absence of information? The majority of features haven't had any updates since they've been initially entered. (I know I'm pretty guilty in this regard). I don't see how a project tool by itself can solve this - it's still garbage in/garbage out. Bill -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
