Gmane
From: Free Ekanayaka <free <at> miu-ft.org>
Subject: Re: Uploading A/DeMuDi packages to Debian
Newsgroups: gmane.linux.agnula.general
Date: 2006-01-21 09:07:10 GMT (4 years, 2 weeks, 5 days, 16 hours and 29 minutes ago)
|--==> Junichi Uekawa writes:

  JU> Hi,
  JU> Anyway, I'm interested in merging what's available in DeMuDi into
  JU> Debian proper, and getting crufty frameworks polished, and
  JU> up-to-speed.
  >>
  >>That's  perfectly in  the spirit of  A/DeMuDi;  as far as was possible
  >>I've always tried to upload back to Debian what was done in A/DeMuDi.
  >>
  >>One big obstacle is  that  I'm not yet a  DD,  though I've passed  the
  >>tests of the NM process almost one year ago, see:
  >>
  >>https://nm.debian.org/nmstatus.php?email=free%40agnula.org
  >>
  >>I was put on hold  because my GPG  subkey was expired. I've created  a
  >>new one and pinged the DAMs a couple of times, no reply :/

  JU> For this particular problem I think you'll have to demonstrate that
  JU> you are now in control of gpg intrinsics, which shall need a bit more
  JU> time. 

I've suspected something like  that, but what  disappointed me most is
that I got no reply to my mails.

  >>I have   a few packages  in  the  archive yet,  and  I  find it  a bit
  >>difficult to  maintain them (or upload new  ones), as I always need to
  >>bother some DD to sponsor me. So I often end up using mentors.d.n..

  JU> In my experience so far, co-maintenance model seems to be less of a
  JU> hassle.  Sharing a CVS/svn/arch tree with several people, and
  JU> uploading the resulting package is much easier than inspecting a
  JU> package tarball/diff/.dsc.

Yes, that would be a perfect  model for me.  I  don't care too much of
uploading myself or having somebody else who upload  on my behalf, but
he has to   be responsive and  check  the packages  when  it's time to
upload.

  JU> 1. patched kernels -- they can enter Debian as tailored kernels,
  JU> probably after a few disagreements with FTP team and
  JU> debian-installer team for having too many kernel flavors
  JU> 
  >>
  >>Having the  kernel  in  the  archive  would  be  great, but   even
  >>maintaining it outside  it's  not  bad, especially once   that all
  >>kernel-patch packages of the case are in the pool.
  >>
  >>Note   also that  the    most   important  patch  for   A/DeMuDi,  the
  >>realtime-preempt one, usually  doesn't   apply cleanly on   the  patch
  >>Debian kernel source, and  would require some modifications (however I
  >>recently noticed that since the  latest 2.6.15, it applies cleanly  on
  >>Debian sources too).

  JU> It would be nice to have some communication with debian-kernel
  JU> guys. They tend to be around on #debian-kernel <at> opn irc channel or the
  JU> mailing list, and are quite active.
  >>

Good.

  JU> 2. patched packages -- they can enter Debian with patches merged,
  JU> probably having a coordinated effort using debian-multimedia ML as
  JU> a place for coordination
  JU> 
  >>
  >>Sure.  Actually there  are very few   patched packages, for most  I've
  >>submitted bug to the BTS, but I'd like the divergence to be eventually
  >>zero.

  JU> Okay, that's fine.

  JU> I'm suspecting that there are quite a few packages that are not
  JU> updated in Debian archive but are in agnula. It would be nice to get
  JU> them included to Debian.

  JU> Let's start with the easy part: I'll do the sponsoring, or
  JU> co-maintenance; whichever you prefer, to decrease the difference
  JU> between Debian and what's in DeMuDi.

  JU> I guess this is it:
  JU> http://demudi.agnula.org/packages/PACKAGES.LIST

  JU> ...ah, there is already a DeMuDi subversion repository.

  JU> Could you add me to the project ? I'm 'dancer <at> debian.org'.

There's also an Alioth project:

http://alioth.debian.org/projects/demudi

along with a subversion repository:

http://svn.debian.org/wsvn/demudi

My original plan   when I've applied  for the  Alioth  project was  to
create a working area for maintaining packages in the multimedia area.
This  is simpler than spawning a  new project for every package, which
are often very simple. That's why I  wanted to name the Alioth project
as  "debian-multimedia", I didn't want to  put the stress on A/DeMuDi,
but the length of the name exceeded the limits :/

Now we could consider the idea again.. what do you think?

Cheers,

Free