[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pre-BOF CDD ideas



>>>>> On Wed, 2 Jun 2004 14:12:35 +0200 (CEST), Andreas Tille <tillea@rki.de> said:

    Andreas> On Wed, 2 Jun 2004, Free Ekanayaka wrote:
    >> I fit perfectly in this situation. I'm not (yet) a DD (my
    >> application is hanging somewhere on Debian servers..), but I
    >> have lots of things related to aGNUla/DeMuDi that I'd like to
    >> upload and maintain. I set up my own repository at
    >> http://apt.agnula.org/demudi/, but I'd like to avoid that.
    >> 
    >> In Valencia we agreed that this list should act as link between
    >> unofficial CDD developers and Debian, so if the DDs on
    >> debian-custom could help non-DDs uploading their packages that
    >> would be great.

    Andreas> Is there at least one DD in the aGNUla project?  

Not currently.

    Andreas>This one
    Andreas> could sponsor your packages.  If not I have no doubt that
    Andreas> anybody else would sponsor your packages.  Just ask for
    Andreas> sponsoring before setting up a private repository.  Did
    Andreas> you just sended ITP bug reports and asked for sponsors
    Andreas> inside the ITP?

Ah.. that's could be a good idea.  I've sent the  most of the relevant
ITP bug  reports, but I  did not  mentioned  I need a  sponsor for the
packages.

Guenter Geiger kindly sponsored  me some of the  packages, but I can't
ask him to sponsor the rest. So  I think I'll  followup those the rest
of ITP bug reports I opened, as you suggest.

Shall I  open ITP  bug reports even  for  the DeMuDi  native  packages
(task, config and debian installer packages)?

    >> IMHO having different flavours of the same package should be
    >> considered an extreme solution, when no other alternative is
    >> available. As a general rule I think complexity should be kept
    >> at the minimum possible value, and having 2 packages for the
    >> same software means that you have to double the work. Just
    >> think when new upstream source comes out.

    Andreas> The best way would be to send patches to upstream which
    Andreas> enables runtime configuration and then wait for the next
    Andreas> upstream release ...  Perhaps this is naive but I can not
    Andreas> imagine a relevant amount of packages that this would be
    Andreas> a general problem.

Me too, but I might be naive as well.

    >> I most cases I think that a patch can be included in the
    >> original package without hurt, by introducing a command line
    >> flag (e.g. /usr/bin/myprog --my-patch) or similar switches.

    Andreas> Exactly.

ciao,

free



Reply to: