qmail and related packages in NEW

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

qmail and related packages in NEW

Gerrit Pape
Hi, I'm quite surprised how the inclusion of qmail and related packages
into sid is handled, or rather not handled, by the ftpmasters.

Within a time-frame of six months I received exactly one rejection mail in
response to two uploads of the packages, a reply to the rejection mail,
and three mails asking about the progress because nothing happened.

http://smarden.org/pape/Debian/sid.html#nonprogress
 Mon, 28 Apr 2008: uploaded packages to ftp-master.
 Tue, 03 Jun 2008: no response, asking for progress.
 Tue, 17 Jun 2008: no response, asking again.
 Sun, 06 Jul 2008: received this REJECT email.
 Mon, 01 Sep 2008: uploaded updated packages to NEW, and sent a reply.
 Tue, 11 Nov 2008: no response, asking for progress.
 Thu, 20 Nov 2008: no response.
 Today: still no response.

Lacking any response, I can only guess what the reason for the delay is.
>From my point of view this reason is questionable, and I stated so in my
response to the reject mail.  Receiving no response within eight weeks
tells me that discussing doesn't work.

On Mon, Sep 01, 2008 at 10:36:07PM +0000, Gerrit Pape wrote:

> On Sun, Jul 06, 2008 at 02:19:30PM +0000, Joerg Jaspert wrote:
> > Aside from these technical - and possibly fixable - problems, we (as
> > in the ftpteam) have discussed the issue, and we are all of the
> > opinion that qmail should die, and not receive support from Debian. As
> > such we *STRONGLY* ask you to reconsider uploading those packages.
> >
> > Qmail is dead upstream and requires a whole set of patches to even
> > begin to work in the manner expected of a modern MTA.  Given this, the
> > fact that this means there is also no upstream security support, and
> > the fact that Debian already contains at least three reasonable MTAs,
> > we see no need to add qmail to the archive. So - please reconsider if
> > it really helps Debian to have those packages. Also feel free to start
> > a public discussion on [hidden email] about the issue,
> > including any relevant information from this email, in order to gather
> > opinions from other project members.
>
> We all know, I guess, that there's lots of different opinions on the
> quality and usability of qmail.  There're people thinking like you, and
> other people, including me, that have a different opinion.  I respect
> your opinion, please respect ours too.  You're free to not install/use
> the packages.  I've been contacted by several people since I announced
> my intention to package qmail, speaking in favor of the inclusion into
> Debian.
>
> A public discussion already took place
>  http://thread.gmane.org/gmane.linux.debian.devel.wnpp/69292/
>
> I think your advise to start a discussion to gather support for the
> packages is backwards.  Debian is about free software and users, the
> qmail packages are free software, and users request the inclusion into
> Debian.  If you are interested in not having qmail in Debian, you are
> free to start a public discussion to find supporters for your position,
> I guess you'll get some objections too.

I've no idea where yet another thread on this list should take us.  To me
the situation is clear.  There's a user base for these packages, and a
Debian developer ready to maintain them.

I count at least three Debian developers speaking in favor of the
inclusion, I've been approached by several users asking me to make my
unofficial packages officially available in Debian, another Debian
developer has a package depending on qmail in the NEW queue.

In my opinion, ftpmasters should reject packages on grounds of Debian
policy or (maybe) the Debian body.  If they wish a permanent rejection of
qmail and related packages, they should try to find that consensus within
Debian, and, if successful, add that decision to
 http://www.debian.org/devel/wnpp/unable-to-package

Can you advise me on how to get out of that dilemma?

Thanks, Gerrit.

See
 http://bugs.debian.org/457318
 http://smarden.org/pape/Debian/sid.html#nonprogress
 http://ftp-master.debian.org/new.html
 http://thread.gmane.org/gmane.linux.debian.devel.wnpp/69292/
for all the details.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: qmail and related packages in NEW

Neil Williams-4
On Fri, 28 Nov 2008 18:12:42 +0000
Gerrit Pape <[hidden email]> wrote:

> Hi, I'm quite surprised how the inclusion of qmail and related
> packages into sid is handled, or rather not handled, by the
> ftpmasters.

Just because a package is free software does not mean it automatically
qualifies for inclusion in Debian. Debian is not a dumping ground for
every piece of free software that can be dragged off long-dead
homepages.

> Lacking any response, I can only guess what the reason for the delay
> is.

IMHO, the response has been given and your replies have not provided
sufficient grounds to change the response. Personally, I think that is
entirely fair.

> >From my point of view this reason is questionable, and I stated so
> >in my
> response to the reject mail.  Receiving no response within eight weeks
> tells me that discussing doesn't work.

Discussions only work when new information is available. Rehashing the
same points in the hope that repetition wins the day is just boring.
 

> On Mon, Sep 01, 2008 at 10:36:07PM +0000, Gerrit Pape wrote:
> > On Sun, Jul 06, 2008 at 02:19:30PM +0000, Joerg Jaspert wrote:
> > > Aside from these technical - and possibly fixable - problems, we
> > > (as in the ftpteam) have discussed the issue, and we are all of
> > > the opinion that qmail should die, and not receive support from
> > > Debian. As such we *STRONGLY* ask you to reconsider uploading
> > > those packages.
> > >
> > > Qmail is dead upstream and requires a whole set of patches to even
> > > begin to work in the manner expected of a modern MTA.  Given
> > > this, the fact that this means there is also no upstream security
> > > support, and the fact that Debian already contains at least three
> > > reasonable MTAs, we see no need to add qmail to the archive. So -
> > > please reconsider if it really helps Debian to have those
> > > packages. Also feel free to start a public discussion on
> > > [hidden email] about the issue, including any
> > > relevant information from this email, in order to gather opinions
> > > from other project members.
To me, that sounds like a perfectly reasonable and calm response to
your original question.

Packages that are dead upstream are always going to be a headache for
the security team and the release team. Bit rot is a constant source of
new bugs as all the packages around the dead one(s) continue to be
developed and improved.

> > We all know, I guess, that there's lots of different opinions on the
> > quality and usability of qmail.  There're people thinking like you,
> > and other people, including me, that have a different opinion.  I
> > respect your opinion, please respect ours too.  You're free to not
> > install/use the packages.  I've been contacted by several people
> > since I announced my intention to package qmail, speaking in favor
> > of the inclusion into Debian.

It isn't just about choosing not to install it, it causes work for the
various teams in Debian - security, release, QA.

There are always different opinions. What matters is whether there is
any new information to bring to the discussion.

> > I think your advise to start a discussion to gather support for the
> > packages is backwards.  Debian is about free software and users, the
> > qmail packages are free software, and users request the inclusion
> > into Debian.

Insufficient. Debian is about quality, not merely quantity.

> > If you are interested in not having qmail in Debian,
> > you are free to start a public discussion to find supporters for
> > your position, I guess you'll get some objections too.

IMHO qmail should continue to be rejected for the reasons explained by
the original rejection response.

(This package is dead, it's joined the bit bucket invisible, it's been
left unwanted and unmaintained by the upstream. Having a debian
maintainer is insufficient - what qmail needs is a new upstream team.)

> I've no idea where yet another thread on this list should take us.

Hopefully, it will convince you that qmail has no place in Debian
until someone thinks it is worth breathing some life into the upstream
code.

> To me the situation is clear.  There's a user base for these
> packages, and a Debian developer ready to maintain them.

Insufficient.

> In my opinion, ftpmasters should reject packages on grounds of Debian
> policy or (maybe) the Debian body.  If they wish a permanent
> rejection of qmail and related packages, they should try to find that
> consensus within Debian, and, if successful, add that decision to
>  http://www.debian.org/devel/wnpp/unable-to-package
>
> Can you advise me on how to get out of that dilemma?

Stop trying to get qmail into Debian?
or
Take on upstream development of qmail and solve all the problems
(whether qmail will then be recognisable compared to the existing
packages that do the same job, I have no idea).

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/


attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

William Pitcock-2
Hi,

On Fri, 2008-11-28 at 20:51 +0100, Neil Williams wrote:
> > Can you advise me on how to get out of that dilemma?
>
> Stop trying to get qmail into Debian?
> or
> Take on upstream development of qmail and solve all the problems
> (whether qmail will then be recognisable compared to the existing
> packages that do the same job, I have no idea).
>

I think issues like these call for an unsupported repository outside of
Debian, but publicized within the community as an unofficial repository
for things like qmail, packages unwanted in Debian proper for the time
being, etc.

That way if people want to run qmail, they can easily get it, but under
the understanding that it was unofficial and totally unsupported by
Debian itself. (A debbugs installation could be provided for maintainers
if necessary though.)

We could also use this repository as a way for teaching new maintainers
(as an alternative to sponsorship, for the most part) -- packages that
people use could be cherrypicked out of this archive by DDs who want the
package in Debian.

Thoughts?

William

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Holger Levsen-2
Hi,

On Friday 28 November 2008 22:42, William Pitcock wrote:
> I think issues like these call for an unsupported repository outside of
> Debian, but publicized within the community as an unofficial repository
> for things like qmail, packages unwanted in Debian proper for the time
> being, etc.

debian-unofficial.org


regards,
        Holger

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

William Pitcock-2
Hi,

On Fri, 2008-11-28 at 23:57 +0100, Holger Levsen wrote:
> Hi,
>
> On Friday 28 November 2008 22:42, William Pitcock wrote:
> > I think issues like these call for an unsupported repository outside of
> > Debian, but publicized within the community as an unofficial repository
> > for things like qmail, packages unwanted in Debian proper for the time
> > being, etc.
>
> debian-unofficial.org

There's a few problems with debian-unofficial.org, as I see it:

1. It has the same quality requirements as Debian proper in terms of
packaging and code quality -- in my way of interpreting things, qmail
would not be acceptable here;
2. I believe, but may be wrong, that [hidden email] is the only person who
can actually add anything to it. So if daniel does not like qmail for
example, it would not be added.

What I propose is something more along the lines of Gentoo's "sunrise"
overlay... a repository that anyone can get upload access to provided
that they understand basic Debian policy and have established that they
will be non-malicious (likely through some sort of indirect uploading
for a few months). Basically a true *community* repo.

This would likely be with the packaging source being maintained in SVN,
so that there is a large amount of transparency in the maintenance
process.

William

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Holger Levsen-2
Hi,

On Saturday 29 November 2008 01:57, William Pitcock wrote:
> What I propose is something more along the lines of Gentoo's "sunrise"
> overlay... a repository that anyone can get upload access to provided
> that they understand basic Debian policy and have established that they
> will be non-malicious (likely through some sort of indirect uploading
> for a few months). Basically a true *community* repo.

just seen on #debian-community

<h01ger> hmmm
<h01ger> "community-repo" makes me think we should setup somethink like
ubuntus PPA on debian-community.org
<h01ger> interesting idea
* h01ger scratches head


regards,
        Holger

Disclaimer: I have absolutly not the ressources to do this or help much with
doing it. But I probably like to see this very much... /me needs sleep.

BTW, d-c.org finally (since a bit of time) provides email and jabber accounts
for Debian contributors!

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Paul Wise via nm
In reply to this post by William Pitcock-2
On Sat, Nov 29, 2008 at 6:42 AM, William Pitcock
<[hidden email]> wrote:

> I think issues like these call for an unsupported repository outside of
> Debian, but publicized within the community as an unofficial repository
> for things like qmail, packages unwanted in Debian proper for the time
> being, etc.
>
> That way if people want to run qmail, they can easily get it, but under
> the understanding that it was unofficial and totally unsupported by
> Debian itself. (A debbugs installation could be provided for maintainers
> if necessary though.)
>
> We could also use this repository as a way for teaching new maintainers
> (as an alternative to sponsorship, for the most part) -- packages that
> people use could be cherrypicked out of this archive by DDs who want the
> package in Debian.

I've long been thinking a debian-unsupported.org archive; something
for all those packages that we don't support because they haven't been
good enough to get into Debian or were chucked out of Debian,
basically the Debian answer to Ubuntu's universe. The main reason I
started thinking about this was that I got annoyed when QA folks chuck
orphaned packages (i've changed my mind about this since though).
However, this isn't the only reason I think this is a good idea -
there are lots of packages and package repositories out there that
Debian and our users could benefit from, but that are not up to
scratch enough to support in Debian. Gathering these in one place
would help our users to find packages for software they need but is
unsupported. It would also help Debian get more popcon data about
non-Debian packages and provide a source for rough packages.

Some ramblings about what it might involve:

strictly for packages not in Debian or not updated in Debian - any
package not supported by Debian - it should whine about or reject
directly uploaded packages that have a maintainer or where someone
seems to be "supporting" a particular package by doing lots of
uploads.

automatic merging of packages removed from Debian and packages
uploaded to Ubuntu, Nexenta, Preventa, mentors, revu and any other
Debian-based distros that have public archives.

addition of automatically created packages using the tool that was
recently posted about on debian-devel

software would be a combination of dak, ubuntu's merge-o-matic (or
similar), maybe debbugs, pdo, pts, patches.u.c, maybe DDPO, buildd
stuff, lintian and perhaps others.

DDs would be discouraged from participating since they should be
supporting packages/etc within Debian instead.

Allow uploads from DDs, DMs, NMs, DD-connected mentors.d.n keys,
DD-connected REVU keys, Ubuntu developer keys, Ubuntu MOTU keys and
people in a separate MOTU (master of the unsupported) keyring that is
relatively easy to get into.

Infrastructure should be similarly supported and hosted by mainly
non-DDs; buildds, porting machines and so on.

not sure if integrating debian-ports.org there is appropriate or not,
but maybe it would be a good idea later down the track.

A while ago on -devel there was a post about automatic creation of
rough packages using automatic software discovery and AI techniques
for the packaging, I definitely want to feed that into this idea.

Once all the repositories are merged into one place, then we can
export all their patches against debiann to merge.debian.net and have
that linked from the PTS like patches.ubuntu.com is. More about that
idea here:

http://wiki.debian.org/MergeDerivedDistributions

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Miriam Ruiz-4
2008/11/29 Paul Wise <[hidden email]>:

> DDs would be discouraged from participating since they should be
> supporting packages/etc within Debian instead.

I'm not exactly sure about this. I have quite a lot of packages that I
made for my own usage but I don't have time or interest in maintaining
on a permanent basis. I guess that's something that happens to more
DDs out there. We could upload these packages there as: here you are,
if it's useful for you it's great, but I don't plan on supporting
this package more than this. Does it make sense?

Greetings,
Miry


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Evgeni Golov
In reply to this post by Paul Wise via nm
On Sat, 29 Nov 2008 10:28:58 +0900 Paul Wise wrote:

> Infrastructure should be similarly supported and hosted by mainly
> non-DDs; buildds, porting machines and so on.

Actually I was thinking about something similar yesterday.
Asa non-DD it is very hard to reproduce bugs from arches you don't own,
so why not build a network of buildds, accessible by non-DDs where they
can test their stuff?

Count on me on this, I offer my UltraSparc IIe as a playground :)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

William Pitcock-2
In reply to this post by Holger Levsen-2
Hi,

On Sat, 2008-11-29 at 02:19 +0100, Holger Levsen wrote:

> Hi,
>
> On Saturday 29 November 2008 01:57, William Pitcock wrote:
> > What I propose is something more along the lines of Gentoo's "sunrise"
> > overlay... a repository that anyone can get upload access to provided
> > that they understand basic Debian policy and have established that they
> > will be non-malicious (likely through some sort of indirect uploading
> > for a few months). Basically a true *community* repo.
>
> just seen on #debian-community
>
> <h01ger> hmmm
> <h01ger> "community-repo" makes me think we should setup somethink like
> ubuntus PPA on debian-community.org
> <h01ger> interesting idea
> * h01ger scratches head
As mentioned on #debian-community, I don't think PPAs are the right way
to address this because PPAs are separate from each other, and therefore
require many sources.list lines.

The ideal way to handle this would be to have a single repository. PPAs
solve a different problem, which is giving contributors and developers a
playground to publish their in-progress packages. This is more about
getting packages to users in an efficient way, for maintainers that do
not wish to include those packages in Debian proper for either policy
reasons, code quality reasons, or otherwise.

William


signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Romain Beauxis-2
In reply to this post by Holger Levsen-2
Le Friday 28 November 2008 23:57:09 Holger Levsen, vous avez écrit :
> On Friday 28 November 2008 22:42, William Pitcock wrote:
> > I think issues like these call for an unsupported repository outside of
> > Debian, but publicized within the community as an unofficial repository
> > for things like qmail, packages unwanted in Debian proper for the time
> > being, etc.
>
> debian-unofficial.org

Or, why not
  apt-get.org ?
Or
  mentors.debian.net ?

Honnestly, I fail to see clearly the benefit of it, apart from more confusion
and new issues..

Romain


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo?

Matt Arnold-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Romain Beauxis wrote:

> Le Friday 28 November 2008 23:57:09 Holger Levsen, vous avez écrit :
>> On Friday 28 November 2008 22:42, William Pitcock wrote:
>>> I think issues like these call for an unsupported repository outside of
>>> Debian, but publicized within the community as an unofficial repository
>>> for things like qmail, packages unwanted in Debian proper for the time
>>> being, etc.
>> debian-unofficial.org
>
> Or, why not
>   apt-get.org ?
> Or
>   mentors.debian.net ?
>
> Honnestly, I fail to see clearly the benefit of it, apart from more confusion
> and new issues..
>
> Romain
>
>

I think the goal is to create a common infrastructure, creating a Debian
repository takes resources that some do not have. apt-get.org is great
if you know about pinning and such but otherwise using it can really
bork your system, mentors is a hosting service for packages which will
be part of Debian, at some point. What is needed is a properly
constructed archive, with some of the same procedures NEW, buildds etc.
For packages such as qmail which are useful, but which for some reason
can't be supported in Debian. I also see this as a way for NMs to show
their stuff without the sometimes painfully slow sponsorship process.


Cheers
Matt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkwvogACgkQfGeS0kace83HiQCgjH1jYwTRWh0g0tmsE2CAiSIT
ZAIAn0y26q9W9Es9+Z8qqMn4l9eXt6PU
=e4Kg
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Raphael Geissert
In reply to this post by William Pitcock-2
William Pitcock wrote:
[...]
>
> The ideal way to handle this would be to have a single repository. PPAs
> solve a different problem, which is giving contributors and developers a
> playground to publish their in-progress packages. This is more about
> getting packages to users in an efficient way, for maintainers that do
> not wish to include those packages in Debian proper for either policy
> reasons, code quality reasons, or otherwise.

Solution:
http://their.domain.tld/debian sid main

Why do people even want to care about those packages?
I mean, why would one want to use a package which has dubious quality, dubious
maintenance, dubious origins (can it even be legally distributed/used/etc?),
dubious <insert whatever you want here>?.

If a package is not in shape, then get it in shape.
If they don't know how to setup a simple repository or don't know how to package
and are not willing to learn, then they should just forget about it and install
the software by hand (if they know how to do that, of course).

There's no reason to spend/waste more time/resources on all that extra stuff
only newcomers will, wrongly, use.

Or do we have so much man power that there's no much left to do but to waste it?

>
> William

P.S. no need to reply; I just can't stand seeing this topic being brought to
discussion over and over again, always suggesting the same, silly
IMO, "solutions".

Cheers,
Raphael Geissert



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo?

Matt Arnold-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Raphael Geissert wrote:

> William Pitcock wrote:
> [...]
>> The ideal way to handle this would be to have a single repository. PPAs
>> solve a different problem, which is giving contributors and developers a
>> playground to publish their in-progress packages. This is more about
>> getting packages to users in an efficient way, for maintainers that do
>> not wish to include those packages in Debian proper for either policy
>> reasons, code quality reasons, or otherwise.
>
> Solution:
> http://their.domain.tld/debian sid main
>
> Why do people even want to care about those packages?
> I mean, why would one want to use a package which has dubious quality, dubious
> maintenance, dubious origins (can it even be legally distributed/used/etc?),
> dubious <insert whatever you want here>?.
>
> If a package is not in shape, then get it in shape.
> If they don't know how to setup a simple repository or don't know how to package
> and are not willing to learn, then they should just forget about it and install
> the software by hand (if they know how to do that, of course).
>
> There's no reason to spend/waste more time/resources on all that extra stuff
> only newcomers will, wrongly, use.
>
> Or do we have so much man power that there's no much left to do but to waste it?
>
>> William
>
> P.S. no need to reply; I just can't stand seeing this topic being brought to
> discussion over and over again, always suggesting the same, silly
> IMO, "solutions".
>
> Cheers,
> Raphael Geissert
>
>
>

> Solution:
> http://their.domain.tld/debian sid main

Not for some people.
  Not to mention that most of those repos are improperly constructed,
some aren't even signed!

> Why do people even want to care about those packages?
  Same reason you care about <insert random package from your dpkg
- --get-selections>

> If a package is not in shape, then get it in shape.
  As some people will tell you that isn't always enough

> There's no reason to spend/waste more time/resources on all that extra
stuff
> only newcomers will, wrongly, use.

 You are making the assumption that it will be like Upload > in, without
QA, NEW or anything and that is not what has been proposed.

 > Or do we have so much man power that there's no much left to do but
to waste it?

 This is a volunteer project, so individuals can allocate their time as
they see fit.

Matt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkwy/gACgkQfGeS0kace82B+gCggdV//dBEgLiLU7TdJ4B7IKc+
4HYAn1QxM3zQkFrMC0/1Jvletczopq/+
=siPF
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Bas Zoetekouw
In reply to this post by Paul Wise via nm
Hi Paul!

You wrote:

> basically the Debian answer to Ubuntu's universe. The main reason I
> started thinking about this was that I got annoyed when QA folks chuck
> orphaned packages (i've changed my mind about this since though).

For completeness sake: QA does not thow out orphanes packages just for
being orphaned.  If they are orphaned, RC-buggy, hardly used, and
alternatives are available, only then they are candidates for removal.

Bast regards,
Bas.

--
+--------------------------------------------------------------+
| Bas Zoetekouw      | Sweet day, so cool, so calm, so bright, |
|--------------------| The bridall of the earth and skie:      |
| [hidden email]  | The dew shall weep thy fall tonight;    |
+--------------------|                    For thou must die.   |
                     +-----------------------------------------+


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: qmail and related packages in NEW

Moritz Mühlenhoff-2
In reply to this post by Neil Williams-4
Neil Williams wrote:
> It isn't just about choosing not to install it, it causes work for the
> various teams in Debian - security, release, QA.=20

We've discussed this at the Security Team meeting in Essen and we don't
have a problem with qmail being included in Lenny.

Cheers,
        Moritz


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: qmail and related packages in NEW

Joerg Jaspert

>> It isn't just about choosing not to install it, it causes work for the
>> various teams in Debian - security, release, QA.=20
> We've discussed this at the Security Team meeting in Essen and we don't
> have a problem with qmail being included in Lenny.

Are you aware that qmail and its related packages do have a LOT of code
duplication? Someone tried to reinvent a libc or something, and just
copies it into every package. One bug means fixing all those packages at
once.

And AFAIK thats something the security teams do not like. At least didnt
in the past.

--
bye, Joerg
<mechanix> anyone from the MIA team around? tbm?
<Ganneff> sounds nice. how long do you have to be MIA to get into that team? :)
<mhp> you need to have a pgp key, I suppose. and no gpg one, and only a bo box
<Np237> yes, but it must be expired


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: qmail and related packages in NEW

Moritz Mühlenhoff-2
On 2008-11-29, Joerg Jaspert <[hidden email]> wrote:

>
>>> It isn't just about choosing not to install it, it causes work for the
>>> various teams in Debian - security, release, QA.=20
>> We've discussed this at the Security Team meeting in Essen and we don't
>> have a problem with qmail being included in Lenny.
>
> Are you aware that qmail and its related packages do have a LOT of code
> duplication? Someone tried to reinvent a libc or something, and just
> copies it into every package. One bug means fixing all those packages at
> once.

Which? AFAICS it has some portability layers and you typically need daemontools
for djbware, but I don't see any horrible code copies.

Cheers,
        Moritz


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: qmail and related packages in NEW

Nico Golde
In reply to this post by Joerg Jaspert
* Joerg Jaspert <[hidden email]> [2008-11-29 13:22]:
>
> >> It isn't just about choosing not to install it, it causes work for the
> >> various teams in Debian - security, release, QA.=20
> > We've discussed this at the Security Team meeting in Essen and we don't
> > have a problem with qmail being included in Lenny.
>
> Are you aware that qmail and its related packages do have a LOT of code
> duplication?

No. What I see is a lot of reimplemented stuff but not an
embedded code copy (just had a quick look) which should be
no problem from my point of view.

> Someone tried to reinvent a libc or something, and just
> copies it into every package. One bug means fixing all
> those packages at once.

Can you point me to source code? For the reimplemented stuff
I see no problem, unless its a logical bug this doesn't
apply.

> And AFAIK thats something the security teams do not like. At least didnt
> in the past.

Well at least this was also not a reason to delete a package
from the archive so far.

Cheers
Nico
--
Nico Golde - http://www.ngolde.de - [hidden email] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)

Cyril Brulebois-4
In reply to this post by Romain Beauxis-2
Romain Beauxis <[hidden email]> (29/11/2008):
> Or
>   mentors.debian.net ?

Source-only.

Mraw,
KiBi.

signature.asc (204 bytes) Download Attachment
123