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

[Iago R. <iag...@hi...>]

On Mon, 2004-09-20 at 09:50, Mich=C3=A8le Garoche wrote:
> Le 20 sept. 2004, =C3=A0 9:25, Iago Rubio a =C3=A9crit :
[snip]
> >>> 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.

Good policy, but put's lots of weight on the packager as it must code
and fix, that's a developer task.

> 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.

Ask him to join the cssed-devel and scream here his complains :))

> > 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.

If you "don't know how" you cannot do it. If "it cannot be done" nobody
can do it ;)

There'll be things non portable as mmap for windows or ipc for Mac.

> >> 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).

Well, lot's of people adds features to packages. As example Fedora ships
ls with the new -Z option for NCSA/SElinux contexts.

It's also based in the original sources ... but extended a bit.

Meanwhile you publish your code, and document the changes, it's up to
you to add anything to cssed.

> >>> 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.

Of  course no major release will contain no important features :)

If a small feature is added it will be release as revision # ( mean
0.3.1 "adds a turtle icon to the toolbar, once clicked cssed will run
twice slower" ;)
--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD