Matt Taggart wrote: >> Well, this is one of those items where it's not clear what the 'correct' >> answer is. >> Bob and I both felt that Warning was too strong. Nothing is 'wrong' >> it's just that a file exists that could possibly be updated. For some >> products, debian will go into a mode where you can use your copy, >> replace, diff or edit. >> > > Read what I wrote in bugzilla about this > > http://bugs.linux-foundation.org/show_bug.cgi?id=343#c1 >
Ah, saw that and forgot about it. Thanks for the pointer. I think that for single system, we should save the one we find (if it exists) and always regenerate the scheduler file. > >> I think ideally, that is what should happen on >> debian, for RH based releases, I'm not sure what they do. I just ran >> into a situation where phppgadmin MADE me update it's conf file to the >> dist one. I felt that was too strong a nudge. I still like NOTE: for >> this particular situation. >> > > Just the Scheduler.conf case? What do you think about the other cases? > The only ones I remember were for conf files or are you talking about the fossy user etc.... Well my personal opinion is that in general I see lots of these types of warnings and I often think they are overkill, where a NOTE would to just as well. IMHO. But having said that, I don't think spending lots of time discussing Warning -vs- Note is fruitful either. So if you feel strongly about, please change things on the 1.1.0 as appropriate and we will call the matter done. How is that? > >> As for the case of specifying --overwrite or changing the makefile, I >> don't see this as an issue, they want new copies of those files. I >> don't see the point as to how Warnings relate to this particular case. >> > > They don't, that's exactly the point I was making: informed users that ask > for new files won't see the WARNING. > Ahh.... > I have an idea to allow the user to select if they want overwrite or not, I > will implement it soon. I'll have to think about how that affects what > warnings we issue. > Great, but we need to finish 1.1.0 so I expect that the wording changes will happen for 1.1.0 and your implementation can go into 1.2. Glad to see you thinking about it. -- Mark Donohoe MOST/OSTT, Cupertino CA. fossology.org _______________________________________________ fossology mailing list [email protected] http://fossology.org/mailman/listinfo/fossology
