Re: [cssed-devel] New plugin: developer doc plugin

[<mic...@ea...>]

Le 20 sept. 2004, =E0 9:25, Iago Rubio a =E9crit :

>> Well not sure, may be three or four times a year is a balance. When =20=

>> you
>> release small changes you have not a clear vision of the whole =20
>> package.
>> And in the case of this release, there was a complete change of the
>> architecture, so that may not be a good criteria of comparison.
>
> It's just to follow "Release Early, Release Often" :)
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/=20=

> ar01s04.html
>
>>> Of course in Mac world, you've got the word about when a new feature
>>> deserves a release or not :)
>> No, that's not the way it works. If I maintain a package, I have to
>> port any new release, be it at my convenience or not.
>
> No other distros do that. As example Gentoo only packaged "full"
> releases ( they relesed 0.1 and 0.2 ), and RedHat is  still in 0.1.
Yes, I know, but this is the Fink policy. Of course I have to disable =20=

what does not work at all or is not at relevant, but should patch what =20=

is possible to run with a patch.

That's the theory, and you can be sure that if I don't make a release =20=

as soon as you do one, I have mailing either in my box or directly in =20=

user's/developer's mailing list complaining I don't port the new =20
release. That's Mac users, they are used to have the most updated thing =20=

quickly.

> The packaging proccess is not exactly the same as the development
> proccess. Packagers must follow some considerations that developers =20=

> have
> no need to take into account.
Yes, I know, but I make both, so when I think about code, I think also =20=

about portability on the Mac.

> As a packager, you must ensure the release will fit in your =
environment
> and if it does not fit, you should not package it just because it was
> released.
No, except that I have kind of duty to make it portable, if possible at =20=

all. Not just drop it because I don't know how to port it.

>> And if the
>> package does not contain a feature, I cannot release it as part of =
the
>> package, unless I develop myself a part and release it as
>> developer/maintainer.
>
> Well, lots of packagers adds - or cuts - features on the main package.
> RedHat use to modify most packages they release, and they adds any
> feature they think will be ok for RedHat's desktops.
I can cut, I can patch, but I cannot add, because I should use the =20
original package, not a package of mine. That's Fink policy (it's a =20
package manager, no more, so it's based on the original sources).

>>> As example if 0.3.2 would be released with a new short of ipc queue,
>>> useful on BSD and Linux, but useless for you, it's in your hands to
>>> release on Mac or not ;)
>> No, I should release it, even if this does not add anything to the =20=

>> Mac.
> I still think you have no need to do it :)
Well, maybe I can drop a revision if it really add nothing to Mac, but =20=

not a major release in the same condition.

Mich=E8le
<http://micmacfr.homeunix.org>