Posted: 11/18/2003 Re: [fd-dev] FreeDOS 1.0 to-do list Aitor Santamaria Merino wrote: > Jim Hall escribi::: > > > I'm not going to make changes to the "FreeDOS 1.0" to-do list by going > > around the list maintainer. That's no better than making changes to > > someone else's program and releasing it without discussing it with the > > maintainer. And all that achieves is a division in the fd-dev community. > > Many thanks. I want to note that I have always been open to third party > opinions, and ideas, and changing things here and there, and in case of > disagreement, tried to capture the opinion of the majority of the list > (yet if few people contributed). > However, I just believe that this task has been open for a long time, > and noone seemed to care about the milestones. But now that I do, > > > Bugs for "FreeDOS 1.0" that are fixed will still show up as fixed. > > Bugs that are open and part of the "FreeDOS 1.0" milestone will appear > > in the query. If someone makes a non-followup change to a bug (for > > example: changing the milestone, or changing the bug status) there's > > an audit log of the change, including who made it. > > But does it mean that the changes actually happen anyway? Will this log > be available as a list for all the tools? > I've had an off-list discussion with (separately) Eric and Aitor about the 1.0 to-do list. By way of reply to the group, here are some excerpts from those discussions: I've started updating Bugzilla with the "FreeDOS_1.0" milestone. You may have noticed that I added the milestone definition in Bugzilla. Today, I started assigning bugs to that milestone. Unfortunately, it looks like there are LOTS of bugs on the FreeDOS 1.0 to-do list that are NOT in Bugzilla. That should change. "If it's not in Bugzilla, it doesn't exist." Bugs that are in Bugzilla are marked with a "*" in the to-do list. I may have missed some. Aitor and I are discussing the future of the to-do list, to see if it wouldn't be better to keep it an html list, one that Aitor can more easily maintain. If you want to see how the milestone feature gets used in Bugzilla, you can view all bugs in the "FreeDOS_1.0" milestone using this query: http://www.freedos.org/bugs/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&target_milestone=FreeDOS_1.0&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time That's a long URL, so you can shorten it by eliminating some extra fields, like this: http://www.freedos.org/bugs/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&&target_milestone=FreeDOS_1.0&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time From there, you can click on the headers in the results table to sort by bug ID, project name, severity, ... whatever you want to sort by. Anyway, that should help you see what a to-do list would look like in bugzilla. A problem with using bugzilla is in making changes. Should the list be maintained by a single person, or should anyone be able to assign a bug to "FreeDOS_1.0"? The Bugzilla system was created under the assumption of trust, that every member who contributes to Bugzilla can be trusted not to fsk things up for everyone else by making changes on their own. In general, most open Bugzilla systems (like ours) encourage users to NOT change the bug status for projects or bugs that don't belong to them. You contribute by adding comments to bugs, and by emailing the person who owns the project or the bug and suggest fixes, or suggest how the bug can be modified. Once you have demonstrated that you can be trusted (by making several "trusty" change suggestions) the bug owner will usually extend an invitation to make changes yourself. The same concept applies in most open CVS repositories, BTW. But if there's someone in an open Bugzilla that can't be trusted, then it throws everything up in the air, because that person can go and change the status on bugs that don't belong to him. I could lock down our Bugzilla system to keep this from happening, but I'd rather keep it open. An open Bugzilla helps to build a community, because everyone becomes an active participant in adding and fixing bugs. When I look at the to-do list, I think "what bugs _really_ need to be fixed in order to make a 'FreeDOS 1.0' release?" IMO, if a bug gets listed on the to-do list, then it should be very important, something that is missing in our FreeDOS that was important in MS-DOS. Yes, I'm implying that we don't have to match 100% what MS-DOS did. I know the "About FreeDOS" page says that we aim to provide a 100% MS-DOS replacement. But, we've already deprecated some commands in the Spec because they were considered crutches to MS-DOS (for example, APPEND) so we'll never become 100% like MS-DOS (not all the commands will be there.) So that's why I focus more on what do we need to present ourselves to the world as "FreeDOS 1.0". I suppose this reflects my general view that I have as an IT Manager at work: "adequate" vs. "ideal". Everyone wants to have the ideal solution or ideal technology, but that is often very expensive or difficult to implement. And by the time you reach the ideal, the need for that technology may have passed, or technology has changed so that the ideal needs to change. So you often need to focus on the adequate solution - what gets the job done. There's nothing wrong with an adequate solution. By definition, "adequate" is something that fits your needs and works. It just might not be 100% bug free, but certainly something you can use. Anyway, I've already sent some comments to Aitor off-list. He may re-post some of those comments here. -jh >> the Bugzilla "to-do" list was later dropped. Aitor will be picking up the role of "to-do" list maintainer.