somehow i got inspired to reply in a little bit longer text ... Le Tuesday 06 December 2005 23:10, Benoit Chesneau a écrit : | We need this kind of patch right. But only this kind of patch other | wouldn't be in archlinux to my mind.
thats also my way of thinking about things. some minor changes may help
make some packages standards-compatible (freedesktop.org .desktop file
additions and things like that) but otherwise, i try to minimise playing
with the original code of packages... and i think all other devs think
the same. sometimes however, it is difficult to see the complexity of a
package if you are not maintaining it or know the person who wrote it or
you use it daily.
if you find some patches that are not needed for the "optimal", "KISS"
working state of an app, please bring the example in discussion and post
a bug... then we can argue in the case being. in my eyes a patch can be
* essential (not compiling, not running, crashing, ARCH
incompatibility, ...)
* bugfix / backport (devs do not provide backports, their release schedule
is once every 2 years or something like this)
* compatibility restoring (old good written app, modern standards)
* minor feature enhancenment (e.g. add "export to PDF" for a "export to
PS" only app)
* mayor feature enhancenment (// should not happen in building / packaging
stage!! //)
* eye candie
* nonsense
following is my philosophy on how to classify them for building /
packaging software for someone else (e.g. a community)... they are not
for private use of patches... if you have time and resources to play with
patches at home on your machine, feel free... but do not email me to
include it to a package others use if its against my following
guidelines:
i think the first 3 classes are cases, where it is highly advisable to
patch for a package.
4+5: the feature enhancements can be discussed upon and if the developers
of the app can be reached, it should be addressed to them and not trying
to add features and make arch package drift from original code. (actually
i cannot think of such patches to exist in public repos...) especially
mayor changes like changes in API or other messing around should not
happen at the level of building and packaging software but it should be
taking place upstream at the "source". ;-)
the last two are in most cases not to be used.
the eye candie stuff can be in rare cases also enhancing usability where
then it should be considered... but this are really rare cases. (in
public repos, i cannot think of any such example - in my local repos i
have 2 cases, where the app is using hardcoded colour for gui) --- and
nonsense patches (like addapting API to also accept backwards
compatibility, messing with processes, optimisations, ...) i would
completely disqualify to be used ever, except on private machines, done
by people who have a lot of time to play with things. of course from such
playing it may be found a great feature-enhancement everybody waited
for... but (and i already got 2 such emails some months ago) please do
not come to the maintainer of packages but go directly to the devs of the
source and address them with your results to be integrated. this is also
upstream handling.
ok... that's my personal opinion and my ethos (the way i do things) on
this matter. if somebody wants to write guidelines upon this text, feel
free but dont quote me to have told that this are "rules". they are not!
things like that may at maximum be guidelines. also do not expect to have
laws and punishment on such guidelines... on the other hand: expect
people to have common sense and it will happen the right way... and if
not, maybe it happened by a mistake the author (me or others) would be
very happy to have been noticed about.
"life is patchwork!"
-- Damir Perisa, 2003
(a little bit out of context (it was a biology situation), but this quote
suits here fine)
greetings,
Damir
--
We are MicroSoft. You will be assimilated. Resistance is futile.
(Attributed to B.G., Gill Bates)
pgp9YAXTvgxvN.pgp
Description: PGP signature
_______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
