Re: Pre-BOF CDD ideas
>>>>> On Wed, 2 Jun 2004 14:12:35 +0200 (CEST), Andreas Tille <email@example.com> 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?
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
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.