[Debburn-devel] common maintainer mailing list for low-level burning apps and libs

[Simon Huggins]

[debburn-devel cc'd since readers there probably want to know.  Hence
whole mail left; please trim]

On Sat, Jan 30, 2010 at 03:26:43PM +0200, George Danchev wrote:
> Hereby I would like to propose usage of common mailing list
> (debburn-devel) for all the packages involved in low-level burning and
> image manipulation process.

> As of now all they have their lists on alioth, which is somewhat
> suboptimal in my opinion and there is room to avoid unnecessary
> subscriptions or searching through several list archives given as
> maintainer address.

> Why common list:
>
> * most of the low-level burning apps and libraries tend to have common
> or similar source of problems, so sharing symptoms and diagnosises
> would be helpful.
> * some apps (excluding GUIs) reuse or rely on other apps or libraries.
> * that would help to discuss more closely and eventually alleviate
> more efficiently the issues during the 'transfer of authority' from cdr* 
> to alternatives.
> * that would help external packages like GUI frondends which could use
> more than one low-level app/lib like versatile brasero to find their way
> in case of not yet clear source of issues concering the lower level.
>
> Why debburn-devel:
>
> * most of the cdrkit maintainers are already there, so we get their
> subscription for free.
> * most of the other packaging lists seems to be unused.
> * the name seems to be project neutral.
> * some upstream authors are already subscribed there too.
>
> That being said, I see setting Maintainer field of libburn, libisofs,
> libisoburn, dvd+rw-tools, libcdio (did I miss any low-level app/lib?) to
> debburn-devel at lists.alioth.debian.org and have their maintainers
> subscribed there as a useful optimization, which was my motivation to
> propose this.
>
> Other similar suggestions or eventual rebuttals welcome.

I don't have a problem with moving maintainer addresses onto a common
list but I suspect what would happen is that there would be a lot more
noise on the debburn list and that people may unsubscribe.

Most people aren't very interested in all the associated noise from dak
for things they don't directly maintain or if they are they subscribe to
the PTS for that package.

Perhaps a better way is to highlight bugs there and new library releases
on that list and to encourage all the maintainers of packages to
highlight common bugs there.

Simon.

-- 
oOoOo   "... Alan Cox, but he's actually not human, but about a    oOoOo
 oOoOo      thousand gnomes working in under-ground caves in      oOoOo
  oOoOo              Swansea."  -- Linus Torvalds.               oOoOo