Reindl Harald wrote:
Actually this is possibly another argument for a properly managed DVCS setup?
On other projects I can pick
> critical commits and apply them, and it flags when other bits need to be
implemented as well. Almost does away
> with the need to produce actual releases, but you do need to differentiate
security fixes from simple 'improvements'?
this has really nothing to do with DVCS
a patch is security-critical or not and if he is atomic enough to be sure that
there are no big side-effects to expect it woulld be really fine to include
it directly on the download-page with short-decritpion and date
This was really a heads up for those who are working on _how_ the DVCS system
would work in practice. Managing the code contained in a security patch is just
as important as any other change, and if something is critical then it has to be
in the main codebase anyway? With the correct setup, _you_ could locally manage
your RPM builds in parallel, and as critical patches appear you get a heads up
if you need them? And your local DVCS will track changes to the SPEC-file and
which patches apply?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
