From:
<sch...@in...> - 2007-01-17 15:50:51
|
Gianluca Sforna wrote: >>> We probalby have to make sure ALL security issues have duoble entries >>> for release/devel branches >> I don't understand that statement. > > I'll try to be more verbose. I think we should have, for each security > bug, two actual issues reported. They contains the same info, but one > is reported against devel, the other against the last relased version, > otherwise you never know how is the security status of both. > This seems to be more or less an already used scheme; we should just > make sure all security issues are reported this way. Yes, i acknowledge. So basically we want this: - a bugreport for every security issue AND every version (strict!) - a fixed version in every branch if there is a solution for a security issue OR at least a patch for every branch - No hiding of security issues. Inform about cause and effect, as well as solution public and prominent. Do you agree? If so, then my question is: Victor what do you think about this? Is this possible? >> Also i don't like to have depends on interpreters, if I only >> need them for install/upgrade. In my sense this is ugly. > Well... you already need php for using mantis... Haha, funny. Well acutally yeah. But i don't need it twice! Most people i know (aswell as myself) do use libapacheX-mod-phpX. It does not need a CLI variant of php to run. A php-script as a shell script does need such a cli-variant. Therefore you require it to exist, additional to the module version. That does not make sense and is what i dislike. >> I created sql files myself by doing upgrade manually and let the >> upgrader print the SQL statements (similar for the install). That worked >> well for 0.19.x to 1.0.6 with a problematic environment (non-english, >> german localized) but anyway: For further packaging, that is a >> workaround, not a solution. > agreed, not a solution but it's a smart trick :) Thanks :-) >> I don't know if i could lend you a hand. Do >> you something I can do for your help? > If anything, test the script on your own installation. I'm trying to > find time for finishing it, but work+family+all the rest so far have > prevailed... Well as i said, i dislike the way how you do it (but I think that it may be the best solution at current!). But if i find the time to integrate it into my packages as a test, then i will give you some informations. |