Re: I *love* goodbye-microsoft.com

[Tim Cutts]

On 24 Feb 2007, at 12:44 pm, [EMAIL PROTECTED] wrote:


Strangely, I feel a tiny pang of guilt. I now have an apple box
for the first time in decades.  One of the main deciding factors  
was to

buy unixy goodness :-)


That was my main reason for buying an Apple four or so years ago.


but also to get some exposure to OSX. I tried for
a while to live in OSX, but in the end I installed Debian on it. It's
not that I couldn't build everything I wanted, it's just that not  
having
everything just work is like going back in time ten years. It's not  
that

there isn't ports or fink, but there isn't debian, short of a full
install, and the alternatives don't measure up.  It's not that I
couldn't take debian to osx (in my fevered imagination), it's that I'm
too lazy to even try.


Well, that's sort of what fink is.

I have to sheepishly admit that I use OS X every day on my Apple  
machines.  I don't have Debian installed on any of them - I do my DD  
work on server machines.  The main reason for that is that I still  
think that for GUI things Apple have the edge over any of the Linux  
alternatives.  The UI is simple, functional, and well integrated.   
Debian is fabulous in so many ways, but I still don't think any Linux  
distribution really cuts it on the desktop (although I do administer  
a network of 300 Debian desktop machines at work, so I don't think  
it's *that* bad).


I've also been very pleased to not the fairly vibrant OSS community  
that has grown up around OS X.  There is a *lot* of really quite good  
free software work going on for OS X (Fink, Camino, Adium,  
SSHKeychain being the principal ones I use every single day).  Yes,  
there's a lot of Windows-style shareware too, but I think the free  
stuff is reaching critical mass, when it becomes difficult for the  
shareware authors to justify their position, when that developer over  
there ---> is offering something open and free.


Having said that, when I can justify it to my good lady wife, I'm  
looking forward to buying an Intel Mac and being able to run OS X and  
Linux simultaneously - I tried doing DD work under Virtual PC for a  
while, but it was a non-starter.  Just way too slow.  Just the  
configure script on one of my packages (am-utils, which admittedly  
has the configure script from hell) took more than an hour to run  
under Virtual PC on my 1 GHz PowerBook.


Tim


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

Re: Roundcube

[José Luis Tallón]

gregor herrmann wrote:
> On Sat, 24 Feb 2007 23:27:26 -0200, Fernando M.M. wrote:
>
>   
>> Althought i have already seen some old discussion about packing the
>> webmail Roundcube (1) i have not found the package using the
>> package search (2).
>> 
> [..]
>   
>> Is someone working on it?
>> 
>
> Seems so:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333756
> http://lists.debian.org/debian-webapps/2007/02/msg0.html
> http://lists.debian.org/debian-mentors/2007/02/msg00098.html
>   
I, for one, have kept and maintain my own Roundcube packages since Feb 2005.
However, being "beta" software, and considering that it needs a quite
robust dbconfig-common infrastructure to auto-configure it if packaging
properly, I prefered to wait a bit.

The fact that Neil posted an ITP also kept me away from posting my packages.



Let's see what happens in the next few days. I can also 'dive in' and
provide some patches :-)


Regards,

J.L.


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

On maintainers not responding to bugs

[Nikita V. Youshchenko]

Hello.

What do people look on the following idea: not allow packages to migrate 
from sid to testing if they have unanswered bug reports with severity >= 
normal?

I guess it may be difficult to analyse automatically what is 'unanswered'  
(because there could be follow-ups by submitter and other people, or 
reassigns, or whatever), but perhaps some working heuristic can be worked 
out...


pgpx16Iycirev.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[Steinar H. Gunderson]

On Sun, Feb 25, 2007 at 11:26:45PM +0300, Nikita V. Youshchenko wrote:
> What do people look on the following idea: not allow packages to migrate 
> from sid to testing if they have unanswered bug reports with severity >= 
> normal?

Honestly, this would kill almost any larger package.

The problem is that way too often, maintainers don't really care about
packages migrating to testing. If they did, we wouldn't have 398 RC bugs on
packages that are not in testing...

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Looking for a temporary account on Alpha

[Frank B. Brokken]

Dear Steve Langasek, you wrote:

> > The intention here is to use size_t in situations where the value is known
> > to be non-negative.
> 
> I don't see any reason why you should use size_t for that instead of
> unsigned int.  size_t is intended for use in describing the size of objects
> in memory, not just for anything you know should be non-negative.

Hm, well, your observation is interesting, but I'm not convinced:

https://www.securecoding.cert.org/confluence/display/seccode/INT01-A.+Use+size_t+for+all+integer+values+representing+the+size+of+an+object

>From this:

Any variable that is used to represent the size of an object including,
but not limited to, integer values used as sizes, indices, loop counters,
and lengths should be declared as size_t

One could start a word game here and point out that it doesn't explicitly
state that size_t should be used for non-negative values, but the above
sentence does explicitly mention `not limited to'. Since the examples given
are definitely not limited to `sizes of objects in memory', but rather have
non-negativeness in common, I still consider my position to be correct.

Another interesting one:

Rationale for International Standard?Programming Languages?C
Revision 5.10. April 2003.:

>From that (quotes by me):

6.5.3.4 ... The type of sizeof, whatever it is, is published (in the
library header ) as size_t, since
`it is useful for the programmer to be able to refer to this type.'
This requirement implicitly 
`restricts size_t to be a synonym for an existing unsigned integer 
 type.'
... Thus size_t is also a 
`convenient type for array sizes',
and is so used in several library functions.

So, it's considered a `convenient type' for array sizes; which doesn't state
that it is restricted to that. It does, however, explicitly state that it's a
synonym of an unsigned integer type. 

Finally, I have this one, providing the `philosophical rationale' for using
size_t (at least to me it does):

http://www.cprogramming.com/tutorial/typedef.html

Typedefs and Abstraction

Typedefs provide a level of abstraction away from the actual types being
used, allowing you, the programmer, to focus more on the concept of just
what a variable should mean. This makes it easier to write clean code, 
but
it also makes it far easier to modify your code. For instance, if if you
decided you really needed to support sizes that were too big to store in
an unsigned int, you could make a change in one place in your code--the
typedef itself--to make size_t equivalent to, for instance, an unsigned
long. Almost none of your code would need to change!

But in the end I'm confronted with an error in my program, which I now feel I
can solve thanks to the observation that a size_t * can't always be considered
an unsigned int *. 

The subtlety is, I think, that although the above revision 5.10 states that
size_t is synonym to an unsigned integer type, it doesn't state that it's a
synonym of an `unsigned int'. Could very wel be an `unsigned long int'. Thus I
stumbled over a big endian :-)

Thanks for the discussion!

-- 
Frank B. Brokken
Computing Center, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D  B19F DAC4 BE50 38C6 6170


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

Re: On maintainers not responding to bugs

[Ana Guerrero]

On Sun, Feb 25, 2007 at 11:26:45PM +0300, Nikita V. Youshchenko wrote:
> Hello.
> 
> What do people look on the following idea: not allow packages to migrate 
> from sid to testing if they have unanswered bug reports with severity >= 
> normal?
>

I do not think this is a good idea.  Some packages receive more bugs than the 
maintainer or group of maintainers is able to handle.  And some of these
packages (with a lot of bugs) are very important packages.

Ana


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

Re: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Sun, Feb 25, 2007 at 11:26:45PM +0300, Nikita V. Youshchenko wrote:
> Hello.
> 
> What do people look on the following idea: not allow packages to migrate 
> from sid to testing if they have unanswered bug reports with severity >= 
> normal?
> 
> I guess it may be difficult to analyse automatically what is 'unanswered'  
> (because there could be follow-ups by submitter and other people, or 
> reassigns, or whatever), but perhaps some working heuristic can be worked 
> out...

Bad idea.  This penalizes inremental work.  I.e., package foo gets seven
important bugs filed against it.  The maintainer fixes three and
uploads.  That is certainly an improvement.  Your proposal penalizes
that maintainer for not fixing all of them at one go.  Besides, for
things that are not RC, the sevrities are a bit subjective.  A bug that
is important to the maintainer (because it affects him) might be
wishlist to most users and vice versa.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Looking for a temporary account on Alpha

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/25/07 14:33, Frank B. Brokken wrote:
> Dear Steve Langasek, you wrote:
> 
>>> The intention here is to use size_t in situations where the value is known
>>> to be non-negative.
>> I don't see any reason why you should use size_t for that instead of
>> unsigned int.  size_t is intended for use in describing the size of objects
>> in memory, not just for anything you know should be non-negative.
> 
> Hm, well, your observation is interesting, but I'm not convinced:
> 
> https://www.securecoding.cert.org/confluence/display/seccode/INT01-A.+Use+size_t+for+all+integer+values+representing+the+size+of+an+object
> 
>>From this:
> 
> Any variable that is used to represent the size of an object including,
> but not limited to, integer values used as sizes, indices, loop counters,
> and lengths should be declared as size_t

size_t nargs;
if (parser_number_parlist(&parser, (int *)&nargs, true) == SUCCESS)

It's been a while since I coded in C, so take this for worth, but
what if you do this
  s/(int *)/(size_t *)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF4f+jS9HxQb37XmcRArZLAKDM9VxJG4ILqyIINvNP+3GVF6fCAwCeIDvf
uzKiE/8NtzfxIY8zdosangY=
=Cw1p
-END PGP SIGNATURE-


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

Re: On maintainers not responding to bugs

[Ben Finney]

"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes:

> On Sun, Feb 25, 2007 at 11:26:45PM +0300, Nikita V. Youshchenko wrote:
> > What do people look on the following idea: not allow packages to
> > migrate from sid to testing if they have unanswered bug reports
> > with severity >= normal?
>
> Bad idea.  This penalizes inremental work.  I.e., package foo gets
> seven important bugs filed against it.  The maintainer fixes three
> and uploads.  That is certainly an improvement.  Your proposal
> penalizes that maintainer for not fixing all of them at one go.

Nikita wrote "unanswered", you seem to have misread that as "unfixed".

I believe Nikita is proposing a way to focus on the lack of *any
response* by the package maintainer to particular bug reports, not the
lack of fixes.

-- 
 \"Intellectual property is to the 21st century what the slave |
  `\   trade was to the 16th."  -- David Mertz |
_o__)  |
Ben Finney


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

Re: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Mon, Feb 26, 2007 at 08:30:40AM +1100, Ben Finney wrote:
> 
> Nikita wrote "unanswered", you seem to have misread that as "unfixed".
> 
> I believe Nikita is proposing a way to focus on the lack of *any
> response* by the package maintainer to particular bug reports, not the
> lack of fixes.
> 
Good point.  I did misread.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#412399: ITP: islsm -- Driver for Prism54 "softmac" 802.11 wireless LAN adapters

[Sam Morris]

Package: wnpp
Severity: wishlist
Owner: Sam Morris <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  Package name: islsm
  Version : git-20061017
  Upstream Author : Jean-Baptiste Note, <[EMAIL PROTECTED]>, Feyd,
Denis Vlasenko, Martin Langer <[EMAIL PROTECTED]>,
Christian Lamparter, Holden Karau, 
Xandros, Intersil
Americas Inc., NetChip Technology, 
Inc., Luis R.
Rodriguez <[EMAIL PROTECTED]>, Intel Corporation,
Aurelien Alleaume , 
Conexant Americas Inc.,
David Brownell, Herbert Valerio Riedel 
<[EMAIL PROTECTED]>, Nokia
Corporation, Junio C Hamano, Red Hat, 
Inc., 
  URL : http://islsm.org/~jb/islsm/
  License : GPL
  Programming Lang: C
  Description : Driver for Prism54 "softmac" 802.11 wireless LAN adapters

- -- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (510, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-k7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF4fq+shl/216gEHgRAtPmAKC7KzG5gcKxTcjxi5oowoji5B3AZgCg0XXR
9z//7ImokyUa+b+T6oJvrqI=
=afkU
-END PGP SIGNATURE-


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

Re: On maintainers not responding to bugs

[Sune Vuorela]

On 2007-02-25, Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote:
> What do people look on the following idea: not allow packages to migrate=20
> from sid to testing if they have unanswered bug reports with severity >=3D=
>=20
> normal?

Why not put resources on helping people with the bugs instead of
punishing people ?

You and others are most welcome to take a stab at the 1000 open bugs
against the official kdepackages.

Start here:
http://pkg-kde.alioth.debian.org/bugs.html


Thanks in advance.

/Sune Vuorela
Member of the debian & qt maintainers


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

Bug#412427: ITP: resiprocate -- Session Initiation Protocol (SIP) stack

[Neil McGovern]

Package: wnpp
Severity: wishlist
Owner: Neil McGovern <[EMAIL PROTECTED]>

  Package name: resiprocate
  Version : 1.1rc1
  Upstream Author : ReSIProcate Developers <[EMAIL PROTECTED]>
  URL : http://www.resiprocate.org
  License : Vovida Software License v. 1.0 (3-clause BSD style)
  Programming Lang: C++
  Description : Session Initiation Protocol (SIP) stack
 reSIProcate is a high performance, object-oriented, C++ sip stack that
 is compliant with RFC 3261.
 .
 It has full support for UDP, TCP, and TLS transports on both IPv4 and
 IPv6. It also implements the full set of specifications for DNS usage
 in SIP, including NAPTR and SRV lookups using an asynchronous DNS
 library.

This package will build a couple of binary packages, one library, and
one utility (for now). I intend to work with the pkg-voip team in
producing this, if they want :) (cc-ed)


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

Re: On maintainers not responding to bugs

[Ben Finney]

Sune Vuorela <[EMAIL PROTECTED]> writes:

> You and others are most welcome to take a stab at the 1000 open bugs
> against the official kdepackages.

"You and others" cannot substitute for a response *from the package
maintainer* acknowledging (or otherwise) the bug report. That's the
criterion being discussed here: not a resolution for the reported bug,
but rather a first response from the package maintainer to the bug
report, to acknowledge that it has not been ignored.

-- 
 \ "We demand rigidly defined areas of doubt and uncertainty!"  -- |
  `\ Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas |
_o__)Adams |
Ben Finney


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

Re: On maintainers not responding to bugs

[David Nusinow]

On Mon, Feb 26, 2007 at 11:12:43AM +1100, Ben Finney wrote:
> Sune Vuorela <[EMAIL PROTECTED]> writes:
> 
> > You and others are most welcome to take a stab at the 1000 open bugs
> > against the official kdepackages.
> 
> "You and others" cannot substitute for a response *from the package
> maintainer* acknowledging (or otherwise) the bug report. That's the
> criterion being discussed here: not a resolution for the reported bug,
> but rather a first response from the package maintainer to the bug
> report, to acknowledge that it has not been ignored.

And what he's telling you, and what I'm telling you, is that it's a
completely crap criterion for those of us who deal with massive packagesets
like KDE. Simply replying to a bug won't get it fixed any sooner or
decrease the impact it has on the user. In addition, it distracts us from
doing what is potentially far more productive work.

 - David Nusinow


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

Re: On maintainers not responding to bugs

[Pierre Habouzit]

On Sun, Feb 25, 2007 at 07:27:29PM -0500, David Nusinow wrote:
> On Mon, Feb 26, 2007 at 11:12:43AM +1100, Ben Finney wrote:
> > Sune Vuorela <[EMAIL PROTECTED]> writes:
> > 
> > > You and others are most welcome to take a stab at the 1000 open bugs
> > > against the official kdepackages.
> > 
> > "You and others" cannot substitute for a response *from the package
> > maintainer* acknowledging (or otherwise) the bug report. That's the
> > criterion being discussed here: not a resolution for the reported bug,
> > but rather a first response from the package maintainer to the bug
> > report, to acknowledge that it has not been ignored.
> 
> And what he's telling you, and what I'm telling you, is that it's a
> completely crap criterion for those of us who deal with massive packagesets
> like KDE. Simply replying to a bug won't get it fixed any sooner or
> decrease the impact it has on the user. In addition, it distracts us from
> doing what is potentially far more productive work.

  bleh, you're totally wrong ! That *is* an excellent criterium, if you
need proof, look at the libc: too many unanswered bugs, it should not be
in testing. End of story.

  The releasable set of packages is now void, we can release any minute
now !

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpD8HXkVebpJ.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[Marco d'Itri]

On Feb 26, Ben Finney <[EMAIL PROTECTED]> wrote:

> "You and others" cannot substitute for a response *from the package
> maintainer* acknowledging (or otherwise) the bug report. That's the
> criterion being discussed here: not a resolution for the reported bug,
> but rather a first response from the package maintainer to the bug
> report, to acknowledge that it has not been ignored.
If a maintainer keeps doing uploads we can be almost sure that he is not
"ignoring" bugs too.
Providing an useful answer to a bug requires proper bug triage, which
requires time.
If this is trivial for you then feel free to help with the udev bugs
(it's even easier than the usual package: they are usually bogus and
you can just close them).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Sun, Feb 25, 2007 at 07:27:29PM -0500, David Nusinow wrote:
> 
> And what he's telling you, and what I'm telling you, is that it's a
> completely crap criterion for those of us who deal with massive packagesets
> like KDE. Simply replying to a bug won't get it fixed any sooner or
> decrease the impact it has on the user. In addition, it distracts us from
> doing what is potentially far more productive work.
> 
I have to completely disagree here.  When I started in earnest with the
effort to clean up the sasl package, I literally spent three twelve hour
days in a row doing nothing but bug triage.  I really am not surprised
that people had not offered to help previously.  There were bugs which
had been unanswered for months or years.  And that was for a package
with only ~100 bugs.  When we finally uploaded the new version, it
closed something like 38 bugs.

IOW, having the packages bugs properly organized and triaged is critical
to knowing what you are fixing with each upload.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Ben Finney]

David Nusinow <[EMAIL PROTECTED]> writes:

> On Mon, Feb 26, 2007 at 11:12:43AM +1100, Ben Finney wrote:
> > the criterion being discussed here: not a resolution for the
> > reported bug, but rather a first response from the package
> > maintainer to the bug report, to acknowledge that it has not been
> > ignored.
>
> And what he's telling you, and what I'm telling you,

Actually, this is the first time in this thread that I've seen a
message actually addressing this point. Thank you; at least it's
discussing what the OP was actually talking about.

> is that it's a completely crap criterion for those of us who deal
> with massive packagesets like KDE. Simply replying to a bug won't
> get it fixed any sooner or decrease the impact it has on the
> user.

Getting the bug fixed is surely an important priority; probably the
highest priority. That doesn't mean it's the *only* important thing to
do, though: communication is one of the main reasons the BTS
exists. When a bug is reported via official channels and there is a
long period with no sign that the package maintainer has even read the
report, it is a strong disincentive to sending future bug reports.

> In addition, it distracts us from doing what is potentially far more
> productive work.

The point has been made in many threads that public communication
*about* productive work, or even about progress toward it, is
important to a properly functioning project, in addition to the
productive work itself.

If we can't agree that communication with our users about the issues
they care about is important, I don't think this discussion can go
very far. I am convinced that it is very important for a DD to
communicate with the users of their packages.

Whether the OP's proposal is a good way forward is not something I've
decided. However, I do think that the proposal should be discussed on
the axiom that communication with users in response to the very bug
reports we exhort them to provide is an important task of every DD,
not a "distract[ion] from ... far more productive work".

-- 
 \"My doctor told me to stop having intimate dinners for four. |
  `\Unless there are three other people."  -- Orson Welles |
_o__)  |
Ben Finney


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

Re: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Mon, Feb 26, 2007 at 02:36:13AM +0100, Marco d'Itri wrote:
> 
> If a maintainer keeps doing uploads we can be almost sure that he is not
> "ignoring" bugs too.
> Providing an useful answer to a bug requires proper bug triage, which
> requires time.

Right.  Which means that it should not be ignored.

> If this is trivial for you then feel free to help with the udev bugs
> (it's even easier than the usual package: they are usually bogus and
> you can just close them).
> 

Of course, when starting a software development project, you can also
say "Well, requirements take time.  If you want to help, that is fine,
but in the meantime we have real work to do."  The point is that bug
triage is key to knowing what you are doing in terms of improving the
package you maintain.  Especially if the package is important or
popular.  Even moreso if the package gets lots of bugs filed against it.

Another nice thing about bug triage is that it lets the users (who
report the bugs) know that somebody cares.  I have reported bugs that
have gone unanswered for a year or even two years.  There are probably a
half-dozen like that right now, just which I have submitted.

Regards,

-Roberto

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Sune Vuorela]

On 2007-02-26, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> I have to completely disagree here.  When I started in earnest with the
> effort to clean up the sasl package, I literally spent three twelve hour
> days in a row doing nothing but bug triage.  I really am not surprised
> that people had not offered to help previously.  There were bugs which
> had been unanswered for months or years.  And that was for a package
> with only ~100 bugs.  When we finally uploaded the new version, it
> closed something like 38 bugs.

pff... 100 bugs - that's what we recieve in 6 weeks.

/Sune


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

Re: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Mon, Feb 26, 2007 at 01:45:28AM +, Sune Vuorela wrote:
> On 2007-02-26, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> > I have to completely disagree here.  When I started in earnest with the
> > effort to clean up the sasl package, I literally spent three twelve hour
> > days in a row doing nothing but bug triage.  I really am not surprised
> > that people had not offered to help previously.  There were bugs which
> > had been unanswered for months or years.  And that was for a package
> > with only ~100 bugs.  When we finally uploaded the new version, it
> > closed something like 38 bugs.
> 
> pff... 100 bugs - that's what we recieve in 6 weeks.
> 
Ooooh.  I stand in awe of your greatness.

Seriously, do you think that the number of bug reports you receive is
justification to not answer them?  In fact, I would argue that the more
reports you receive, the more you should endeavour to make sure that
they are properly triaged and that the submitters know you are working
on them.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Pierre Habouzit]

On Sun, Feb 25, 2007 at 08:36:21PM -0500, Roberto C. Sanchez wrote:
> On Sun, Feb 25, 2007 at 07:27:29PM -0500, David Nusinow wrote:
> > 
> > And what he's telling you, and what I'm telling you, is that it's a
> > completely crap criterion for those of us who deal with massive packagesets
> > like KDE. Simply replying to a bug won't get it fixed any sooner or
> > decrease the impact it has on the user. In addition, it distracts us from
> > doing what is potentially far more productive work.
> > 
> I have to completely disagree here.  When I started in earnest with the
> effort to clean up the sasl package, I literally spent three twelve hour
> days in a row doing nothing but bug triage.  I really am not surprised
> that people had not offered to help previously.  There were bugs which
> had been unanswered for months or years.  And that was for a package
> with only ~100 bugs.  When we finally uploaded the new version, it
> closed something like 38 bugs.
> 
> IOW, having the packages bugs properly organized and triaged is critical
> to knowing what you are fixing with each upload.

  IOW, know your distribution. KDE weights 12 or 1300 bugs I think,
maybe a bit less, it was 1700 not so long time ago. I'd bet X.org,
Gnome, OOO.org, fire^H^H^H^Hiceweasel, ... live the same nightmare.

  For the record, the libc had 330 bugs opened quite recently, we're
down to 280 or so I guess, maybe a bit less if we exclude those who have
been tagged wontfix. I'd bet most of them are unanswered, or at least,
completely forgotten.

  I was previously beeing ironic, now I'm not anymore. Such a criterion
sucks, and sucks hard. Most of the huge pieces of software around
generate a load that is barely bearable for the teams that work on them
if you just consider RC bugs, some importants ones, and packaging new
upstreams. Sorry, but sasl, if widely used, remains a _small_ package,
that covers a quite small amount of features. You can't take it as a
general example.

  And btw, help for bug triaging for any of those kind of packages is
vastly appreciated... But here is a newsflash: 100 bugs is fairly easy
to reduce. the 5 or 600 bugs the KDE team has closed was a year of work.
Yes a damn year, during which there has been many upstream releases
(getting a release ready is a week of work, plus the RC that always come
with them, so you can add another week on top of this one). So please
explain me how a team that has had sometimes less of 2 to 3 _actually active_
members at a given time do manage to keep up with bugs as well ? I'll
tell you: they just don't.

  Sorry to seem pissed, but well, I am. Your mail (and others with the
same thoughts) are completely disconnected from reality. Totally.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpQ4i5KAhS20.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[Pierre Habouzit]

On Sun, Feb 25, 2007 at 08:51:17PM -0500, Roberto C. Sanchez wrote:
> On Mon, Feb 26, 2007 at 01:45:28AM +, Sune Vuorela wrote:
> > On 2007-02-26, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> > > I have to completely disagree here.  When I started in earnest with the
> > > effort to clean up the sasl package, I literally spent three twelve hour
> > > days in a row doing nothing but bug triage.  I really am not surprised
> > > that people had not offered to help previously.  There were bugs which
> > > had been unanswered for months or years.  And that was for a package
> > > with only ~100 bugs.  When we finally uploaded the new version, it
> > > closed something like 38 bugs.
> > 
> > pff... 100 bugs - that's what we recieve in 6 weeks.
> > 
> Ooooh.  I stand in awe of your greatness.
> 
> Seriously, do you think that the number of bug reports you receive is
> justification to not answer them?

  errrm, let me think. YES !

  There is a thing to know about bugs, answering "hey, I got your mail"
is useless, vacation can do that. So if we suppose answering means
digging a bit, or forwarding upstream or... it then takes at least 15
minutes (for easy bugs). Up to the hour for some (to try to figure out
what the hell the user meant). And NO those number are not irrelevant,
when I closed sth like 250 or 300 KDE bugs last year, It took me 1 hour
for 3 to 4 bugs when I was quick.

  So now let's do a simple calculation. 100 bugs, 20 minutes, that's
2000 minutes, over 6 weeks, that's 333 minutes a week, meaning at least
6 hours a half of work. Just to keep up with bugs. Of completely tedious
work.

  Add to that: working on the backlog, working on the bugs that in fact
need 1hour of work, packaging new upstreams, doing some maintenance on
the repository and so on, and KABOOOM, either you have a time machine,
or there is not enough time.

  so well, hmm let me think again ... YES THIS IS A DAMN PERFECT
ARGUMENT.

> In fact, I would argue that the more reports you receive, the more you
> should endeavour to make sure that they are properly triaged and that
> the submitters know you are working on them.

  well, that would be a lie: ([EMAIL PROTECTED]) we don't work on them. So all's
for the best, it's just fairly visible that we don't even pretend to,
isn't that great ?

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpHeT3m2ZG0Q.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[root]

On Sun, Feb 25, 2007 at 07:27:29PM -0500, David Nusinow wrote:
> On Mon, Feb 26, 2007 at 11:12:43AM +1100, Ben Finney wrote:
> > Sune Vuorela <[EMAIL PROTECTED]> writes:
> > 
> > > You and others are most welcome to take a stab at the 1000 open bugs
> > > against the official kdepackages.
> > 
> > "You and others" cannot substitute for a response *from the package
> > maintainer* acknowledging (or otherwise) the bug report. That's the
> > criterion being discussed here: not a resolution for the reported bug,
> > but rather a first response from the package maintainer to the bug
> > report, to acknowledge that it has not been ignored.
> 
> And what he's telling you, and what I'm telling you, is that it's a
> completely crap criterion for those of us who deal with massive packagesets
> like KDE. Simply replying to a bug won't get it fixed any sooner or
> decrease the impact it has on the user. In addition, it distracts us from
> doing what is potentially far more productive work.
> 
>  - David Nusinow
Users and developers. Two different animals. Some developers want to fix
bugs and not communicate anything other than "I fixed a bug " and
consider saying "Yes I got your bug report" as a waste of time. Yes, it
is a waste of time in terms of the developers goal of fixing the bug but
it is not a waste of time in regards to extablishing a positive
relationship with "those folks who use the software" aka our users --
like the Debian foundation documents mention--and saying that you
ackowledging their part of the process of software development and not
treating them with distrain. If you treat them well, by acknowleding
their bug reports and -- $DEITY forgive -- saying you are working on it,
even if it takes a $LONG_TIME to fix, they will be patient and will try
to be helpful by testing your work further and proving you with more bug
report or even patches. Communication is not a waste of time. Ever been
in an airport or subway, waiting for an hours and no updates wishing
for someone to tell you what the status is? It makes folks feel better,
even if it doesn't change the situation.
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|   my keysever: subkeys.pgp.net | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Robert Collins]

On Sun, 2007-02-25 at 21:11 -0500, root wrote:
> ... ackowledging their part of the process of software development and
> not
> treating them with distrain. If you treat them well, by acknowleding
> their bug reports and -- $DEITY forgive -- saying you are working on
> it, ...

In fact, acknowledging and saying 'I dont have time to fix this' is
important too: it means that other developers, or users wanting to be
developers, know that they wont collide with the developer should they
try to fix it. 

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Where did Bacula 1.38.11-7+b1 come from?

[Guillem Jover]

On Fri, 2007-02-23 at 19:13:09 +0100, Florian Weimer wrote:
> * Guillem Jover:
> > The resulting .changes will get a field like this:
> >
> >   Source: bacula (1.38.11-7)
> >
> > which can be used to track back from which source this binary
> > originated.
> 
> Yeah, but this only helps if you've got a source version to compare
> to.  You could derive that from a binary version if you've got the
> corresponding Package entry, but this information might not be
> available anymore when you need it.

Sorry if I was unclear, but this field with that information is present
in the binary packages and then exposed through the Packages file. It's
even on dpkg's status file.

> Furthermore, it's not particularly useful to address the
> inconsistencies added by binNMUs when there are other problems.  Some
> binary packages have different version numbering schemes on different
> architectures, or they are built from different source packages.

The only current problem I see from the binNMU implementation in dpkg
is that packages that have a different source version than the one for
the binary packages will not receive a proper binNMU version as those
package generate the version manually, neither the binary:Version will
be correct, as we'd have to introduce a binary::Version or
similar to be able to deal with those. Given the small amount of
packages doing this I decided to implement something that'd work for
almost all packages except for the few odd cases, that would be
problematic anyway now. This could be fixed in the future if there's
a pressing need.

regards,
guillem


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

Re: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Mon, Feb 26, 2007 at 02:55:39AM +0100, Pierre Habouzit wrote:
> 
>   And btw, help for bug triaging for any of those kind of packages is
> vastly appreciated... But here is a newsflash: 100 bugs is fairly easy
> to reduce. the 5 or 600 bugs the KDE team has closed was a year of work.
> Yes a damn year, during which there has been many upstream releases
> (getting a release ready is a week of work, plus the RC that always come
> with them, so you can add another week on top of this one). So please
> explain me how a team that has had sometimes less of 2 to 3 _actually active_
> members at a given time do manage to keep up with bugs as well ? I'll
> tell you: they just don't.
> 
>   Sorry to seem pissed, but well, I am. Your mail (and others with the
> same thoughts) are completely disconnected from reality. Totally.
> 
Sorry.  I was arguing for the value of bug triage and communicating with
submitters.  I still on't think that holding up migration over
unanswered bugs is a good idea.  Hope that clears things up for you.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Roberto C. Sanchez]

On Mon, Feb 26, 2007 at 03:03:17AM +0100, Pierre Habouzit wrote:
> > 
> > Seriously, do you think that the number of bug reports you receive is
> > justification to not answer them?
> 
>   errrm, let me think. YES !
> 
>   There is a thing to know about bugs, answering "hey, I got your mail"
> is useless, vacation can do that. So if we suppose answering means
> digging a bit, or forwarding upstream or... it then takes at least 15
> minutes (for easy bugs). Up to the hour for some (to try to figure out
> what the hell the user meant). And NO those number are not irrelevant,
> when I closed sth like 250 or 300 KDE bugs last year, It took me 1 hour
> for 3 to 4 bugs when I was quick.
> 
>   So now let's do a simple calculation. 100 bugs, 20 minutes, that's
> 2000 minutes, over 6 weeks, that's 333 minutes a week, meaning at least
> 6 hours a half of work. Just to keep up with bugs. Of completely tedious
> work.
> 
>   Add to that: working on the backlog, working on the bugs that in fact
> need 1hour of work, packaging new upstreams, doing some maintenance on
> the repository and so on, and KABOOOM, either you have a time machine,
> or there is not enough time.
> 
>   so well, hmm let me think again ... YES THIS IS A DAMN PERFECT
> ARGUMENT.
> 
OK.  But is there not a fairly sizeable team working on KDE packaging
for Debian?  If you were doing it all by yourself, your argument would
make perfect sense.  However, there are others who can help.

> > In fact, I would argue that the more reports you receive, the more you
> > should endeavour to make sure that they are properly triaged and that
> > the submitters know you are working on them.
> 
>   well, that would be a lie: ([EMAIL PROTECTED]) we don't work on them. So 
> all's
> for the best, it's just fairly visible that we don't even pretend to,
> isn't that great ?
> 
OK.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Ana Guerrero]

On Sun, Feb 25, 2007 at 10:35:48PM -0500, Roberto C. Sanchez wrote:
> OK.  But is there not a fairly sizeable team working on KDE packaging
> for Debian?  

No. FYI, the KDE team is currently about 6 *active* members, 3 working 
a lot and 3-4 working when they have some free time. Last kde 3.5.6 has been
packaged for only 3 members of the team (one of them is not even in NM).


> If you were doing it all by yourself, your argument would
> make perfect sense.  However, there are others who can help.

MadCoder has done a lot of work of packaging/bug triaging/maintaing of
KDE in the past. I understand very well the frustration he had when he
wrote some of the mails in this thread.

Ana


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

Re: On maintainers not responding to bugs

[Don Armstrong]

On Mon, 26 Feb 2007, Ben Finney wrote:
> Sune Vuorela <[EMAIL PROTECTED]> writes:
> 
> > You and others are most welcome to take a stab at the 1000 open bugs
> > against the official kdepackages.
> 
> "You and others" cannot substitute for a response *from the package
> maintainer* acknowledging (or otherwise) the bug report. That's the
> criterion being discussed here: not a resolution for the reported
> bug, but rather a first response from the package maintainer to the
> bug report, to acknowledge that it has not been ignored.

There's nothing magical at all about the package maintainer. Anyone
can respond to any of these bugs with more information that clarifies
what the actual bug is, patches, and other information.

Package maintainers are ultimately responsible for the bugs in their
packages, but they can't possibly respond to them all.

[Frankly, if you're concerned about whether someone has seen your
mail, surely the ack from the BTS is sufficent. Anything else requires
someone to actually do the work.]


Don Armstrong

-- 
Of course, there are cases where only a rare individual will have the
vision to perceive a system which governs many people's lives; a
system which had never before even been recognized as a system; then
such people often devote their lives to convincing other people that
the system really is there and that it aught to be exited from. 
 -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_

http://www.donarmstrong.com  http://rzlab.ucr.edu