Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jon Dowland]

On Thu, Jul 14, 2005 at 02:55:48PM +0200, Stig Sandbeck Mathisen wrote:
> Jon Dowland <[EMAIL PROTECTED]> writes:
> 
> > I suggest having __two__ lists: a wishlist and a worklist (with the
> > latter being the existing TODOlist)
> 
> A decent idea, since items can be moved back and forth as needed.

I've suggested as such at  and put
a stub page at .

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Stig Sandbeck Mathisen]

Jon Dowland <[EMAIL PROTECTED]> writes:

> I suggest having __two__ lists: a wishlist and a worklist (with the
> latter being the existing TODOlist)

A decent idea, since items can be moved back and forth as needed.

-- 
Stig Sandbeck Mathisen


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jon Dowland]

On Mon, Jul 11, 2005 at 11:50:14AM -0400, David Nusinow wrote:
 
> What I'd like to see is no more new items added to that list without
> someone signing up and taking responsibility for them. What I really want
> to see more than anything with that list is for each and every item to have
> at least one person signed up, taking responsibility for it. That way, it
> becomes a real TODO list, rather than just a stupid wishlist.

I think the TODO list is an incredibly useful tool and I agree that it
shouldn't be clogged up by wishlist items (i.e. items someone thinks
are worthy enough to add, but nobody is up for working on them yet).
However I do think wishlist items serve a purpose too: They demonstrate
a desire from users for a feature that could be picked up on and
converted into a TODO list item by an interested party.

I suggest having __two__ lists: a wishlist and a worklist (with the
latter being the existing TODOlist)

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jonas Meurer]

On 12/07/2005 Max Vozeler wrote:
> On Mon, Jul 11, 2005 at 09:44:07PM +0200, Jonas Meurer wrote:
> > please consider to support luks too. the current cryptsetup package
> > supports only dm-crypt from christophe saout. luks from clemens
> > fruhwirth has many advantages over plain dm-crypt, and i guess that it's
> > quite more common for encrypted disks.
> 
> Is there already support for LUKS in Debian?

no, not officially. but Michael Gebetsroither <[EMAIL PROTECTED]>
provides cryptsetup-luks debs at his own repositority here:
deb http://einsteinmg.dyndns.org/debian unstable/

> I'm very open for this and will keep it in mind, but I have to plead
> ignorance about the practical side of using the luks implementations.
> (I've only read Fruhwirth Clemens' LUKS paper)

unfortunately it's the same for me. i still use cryptsetup from wesley
as i'm too lazy to upgrade my encrypted partitions to luks.

but i have this on my todo list since many months *g*

> The framework should allow to use LUKS in principle, but input from
> people who use it would be required for the actual implementation.  If
> you are interested, or know of someone who is, please let me know.

i think the best person to contact is Michael Gebetsroither. you can
reach him at [EMAIL PROTECTED] i had some conversation about his
packages with him, and it seems to me that he has quite a good
understanding of luks.

bye
 jonas


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Max Vozeler]

On Mon, Jul 11, 2005 at 09:44:07PM +0200, Jonas Meurer wrote:
> On 11/07/2005 Max Vozeler wrote:
> > On Fri, Jul 08, 2005 at 02:33:12PM +0200, Javier wrote:
> > > - Encrypted root/swap on the d-i installation.
> > 
> > I'm planning to work on this- probably during the next few weeks. I hope
> > to also get together with Wesley Terpstra and talk about how we can make
> > the framework usable for both loop-AES and dm-crypt based setups.
> 
> please consider to support luks too. the current cryptsetup package
> supports only dm-crypt from christophe saout. luks from clemens
> fruhwirth has many advantages over plain dm-crypt, and i guess that it's
> quite more common for encrypted disks.

Is there already support for LUKS in Debian?

I'm very open for this and will keep it in mind, but I have to plead
ignorance about the practical side of using the luks implementations.
(I've only read Fruhwirth Clemens' LUKS paper)

The framework should allow to use LUKS in principle, but input from
people who use it would be required for the actual implementation.  If
you are interested, or know of someone who is, please let me know.

cheers,
Max


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Max Vozeler]

On Mon, Jul 11, 2005 at 08:06:29PM +0200, Frank Lichtenheld wrote:
> Nevertheless, we're indeed currently working on such a framework as
> you mention. On our list of tests to run are currently install tests
> (with liw's piuparts), rebuild tests (with pbuilder I think) and
> lintian (perhaps linda, too?). Adding new tests should be not a
> great problem once we have the infrastructure up.

Sweet!

Let me know if you could use help with this. I did a small POC patch
against the scripts to see whether the switch to lintian.d directory
would be feasible, but then didn't finish it for submission. 

I have a small script ready that checks packages for setuid/setgid
files. There are some other things that would IMHO be interesting to
check from a security perspective - we can probably get some good
information from this once the infrastructure in in place.

cheers,
Max


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Steve Langasek]

On Mon, Jul 11, 2005 at 07:40:23PM +0200, Eduard Bloch wrote:
> #include 
> * Jochen Voss [Mon, Jul 11 2005, 10:17:56AM]:

> > > Are we sure we want someone who is routinely this incompetent
> > >  to help with bug triage? Seems to me we would be bette off without
> > >  such substandard help; anyone this incompetent is probably creating
> > >  more problems than they are solving.

> > Great idea!  We can even get mor out of this, if we install some
> > kind of challenge response system: every time you upload a package

> To be honest, I had a similar idea before: every upload has to be
> approved by at least one additional Debian developer. This would
> decrease the probability for really broken uploads (because of stupid
> mistakes or beeing on drugs or whatever).

> The work itself can be automated well, I imagine an IRC channel
> #debian-uploads-looking-for-approval.

Why is this a better option than revoking the upload rights of developers
make sloppy uploads?  I don't expect that *requiring* a second set of
eyeballs on uploads will be any more effective than our NM advocate process
currently is.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jonas Meurer]

On 11/07/2005 Max Vozeler wrote:
> On Fri, Jul 08, 2005 at 02:33:12PM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > - Encrypted root/swap on the d-i installation.
> 
> I'm planning to work on this- probably during the next few weeks. I hope
> to also get together with Wesley Terpstra and talk about how we can make
> the framework usable for both loop-AES and dm-crypt based setups.

please consider to support luks too. the current cryptsetup package
supports only dm-crypt from christophe saout. luks from clemens
fruhwirth has many advantages over plain dm-crypt, and i guess that it's
quite more common for encrypted disks.

bye
 jonas


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Lars Wirzenius]

ma, 2005-07-11 kello 19:40 +0200, Eduard Bloch kirjoitti:
> To be honest, I had a similar idea before: every upload has to be
> approved by at least one additional Debian developer. This would
> decrease the probability for really broken uploads (because of stupid
> mistakes or beeing on drugs or whatever).
> 
> The work itself can be automated well, I imagine an IRC channel
> #debian-uploads-looking-for-approval.

That's a lot of manual work and that is, almost by definition, bad.
Create automated checks instead. For example, just to plug my own
current thing, don't accept the upload unless it passes piuparts
checking, that is, can be installed and removed without ill effects.

And, because Steven Kowalik is sitting on my left side right now,
talking loudly to his laptop, run linda on it and see that it doesn't
find any errors. (Add a way to have an override file for the few cases
when linda is wrong and the package is right, or, of course, fix linda.)

But don't make programmers do more manual work than they absolutely have
to. That won't do any good in the long run.


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Adrian von Bidder]

On Monday 11 July 2005 09.59, Javier Fernández-Sanguino Peña wrote:
> On Sat, Jul 09, 2005 at 08:25:11AM -0500, Manoj Srivastava wrote:
> > This is a huge list, with probably 0 chances of getting
> >  accomplished.  How about this: remove every single item from the list,
> >  and only add items when there are people who sign up to be responsible
> >  for the work involved in actually seeing that item come to fruition?
>
> Errr.. the wishlists with names within brackets are those that have been
> taken over by somebody, the ones that don't are up for grabs.

Except that it isn't true, exactly.  At least in my case - the issue I 
suggested is exactly one of the cases that annoys Manoj so much.

cheers
-- vbi
-- 
"Oh, mi hai uccisa!"
-- Dal film "Quintet"


pgppFGKgKSmdJ.pgp
Description: PGP signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Adrian von Bidder]

On Saturday 09 July 2005 00.39, Steve Langasek wrote:
> On Fri, Jul 08, 2005 at 03:49:36PM +0200, Santiago Vila wrote:

> > IMHO, we should keep dummy packages around for at least two releases,
> > to support upgrades which skip one release.
>
> In practice, upgrades that skip a release are not supported.  There was
> no way at all that upgrades from potato->sarge could have been supported,
> and it's not a goal of the release team to support direct upgrades from
> woody->etch.

While it is only sensible to state in bold, big, fat, huge letters that 
upgrades over two releases are not supported, breakting these on purpose 
does nobody any good when keeping this minor support in doesn't cost more 
than 4k on the mirror network.

cheers
-- vbi

-- 
Beware of the FUD - know your enemies. This week
* Patent Law, and how it is currently abused. *
http://fortytwo.ch/opinion


pgpV5pYml0g0H.pgp
Description: PGP signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Adrian von Bidder]

On Friday 08 July 2005 14.33, Javier Fernández-Sanguino Peña wrote:
> TODO: Should this be in  
> http://wiki.debian.net/index.cgi?ReleaseProposals ?

It's  - which contains a short 
disclaimer on its difference vs. ReleaseProposals.

Manoj:
> Mere wishlists by random bystanders are no help to anyone.

I think I can agree with your sentiment that they don't get things done.  
OTOH I feel it worthwhile to collect these ideas on what people are missing 
in Debian - it does help people to find other people with interests in 
similar areas, and I'd argue that the list does no harm.  If you don't feel 
it is helpful to you, just ignore it.

regards
-- vbi

-- 
Bescheidenheit ist so beliebt, weil sie einem die Arroganz erleichtert.


pgpWK31VqwWEo.pgp
Description: PGP signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Frank Lichtenheld]

On Mon, Jul 11, 2005 at 06:58:15PM +0200, Max Vozeler wrote:
> A first step could be to make the lintian.d.o scripts run on a lintian.d
> style directory of scripts, if that sounds reasonable to the people who
> run that service (Josip Rodin?). That would make it pretty easy to build
> lists of privileged files, plug in source code scanners, greps for /tmp/
> and everything else we can come up with.

lintian.d.o is currently maintained by jeroen and me (kind of, it's
currently somewhat broken and I'm not yet able to find out exactly why,
but that's another story). But that code is really lintian specific.

Nevertheless, we're indeed currently working on such a framework as
you mention. On our list of tests to run are currently install tests
(with liw's piuparts), rebuild tests (with pbuilder I think) and
lintian (perhaps linda, too?). Adding new tests should be not a
great problem once we have the infrastructure up.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Eduard Bloch]

#include 
* Jochen Voss [Mon, Jul 11 2005, 10:17:56AM]:

> > Are we sure we want someone who is routinely this incompetent
> >  to help with bug triage? Seems to me we would be bette off without
> >  such substandard help; anyone this incompetent is probably creating
> >  more problems than they are solving.
> 
> Great idea!  We can even get mor out of this, if we install some
> kind of challenge response system: every time you upload a package

To be honest, I had a similar idea before: every upload has to be
approved by at least one additional Debian developer. This would
decrease the probability for really broken uploads (because of stupid
mistakes or beeing on drugs or whatever).

The work itself can be automated well, I imagine an IRC channel
#debian-uploads-looking-for-approval.

Regards,
Eduard.

-- 
Emperor Turhan: How will this end?
Kosh Naranek: In fire.
 -- Quotes from Babylon 5 --


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Max Vozeler]

On Fri, Jul 08, 2005 at 02:33:12PM +0200, Javier Fernández-Sanguino Peña wrote:
> - Encrypted root/swap on the d-i installation.

I'm planning to work on this- probably during the next few weeks. I hope
to also get together with Wesley Terpstra and talk about how we can make
the framework usable for both loop-AES and dm-crypt based setups.

> [ Security improvements ] 
> 
> - Proper source code audit by maintainers to detect stupid security
>   bugs (/tmp/XX.?? anyone?) Recurrent things like #306893 appear all
>   too often. Automatic source code audit ala lintian.debian.org? 

I'd be happy to help with this effort. 

A first step could be to make the lintian.d.o scripts run on a lintian.d
style directory of scripts, if that sounds reasonable to the people who
run that service (Josip Rodin?). That would make it pretty easy to build
lists of privileged files, plug in source code scanners, greps for /tmp/
and everything else we can come up with.

cheers,
Max


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[David Nusinow]

On Mon, Jul 11, 2005 at 04:56:15AM -0500, Manoj Srivastava wrote:
> > Thanks, but I'm not a random bystander. Even if I were, I don't see
> > how a compiled TODO for the distribution hinders development or
> > rather, as seen in the previous thread, encourages discussion
> > between developers.
> 
> Read http://www.livejournal.com/users/gravityboy/15401.html
> 
> In essence, this is akin to what Andrew Suffield calls "Voting
>  for more money". A reasonable list of reasonable, achievabel goals
>  for Etch is of real value. However, that requires thought, judgement,
>  and triaging out marginal and unrealistic ideas out of the list; and
>  that appears not to have been done.

For what it's worth, I've just signed myself and the X Strike Force (me
being the public face of the thing as of late) up for the X.Org transition
item on the EtchTODO page. I also removed two suprious items related to X
that I don't intend to do, and I don't plan on allowing to pass through the
X.Org packages currently. Seeing as I wrote the above blog entry, I can
take a little responsibility for my piece of that TODO list.

What I'd like to see is no more new items added to that list without
someone signing up and taking responsibility for them. What I really want
to see more than anything with that list is for each and every item to have
at least one person signed up, taking responsibility for it. That way, it
becomes a real TODO list, rather than just a stupid wishlist.

For those people out there who want to work on something but aren't sure
what, just sign up for something on that list and get to work! There's some
cool ideas on there, but we need to actually make them happen, since they
won't just materialize on their own. People in NM or looking to get in to
NM, this is a perfect opportunity to do something cool and help shape the
project. Finally, if you're already working on something, like getting the
new KDE or Gnome in to Debian, put it on there with your name by it! Let's
use this page to show people what's actually happening in Debian, so they
don't have to trawl through a zillion bug reports, mailing lists, and irc
channels just to hear what we plan to do.

 - David Nusinow


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Mon, 11 Jul 2005 09:59:52 +0200, Javier Fernández-Sanguino Peña <[EMAIL 
PROTECTED]> said: 

> Providing a list of things that need to be worked on, even if not
> Release Critical, is a good thing IMHO. 

Umm. I think that such a list has already grown too large to
 be of value; I can come up with a few hundred items along the lines
 of "would be nice if ..".  

>> Mere wishlists by random bystanders are no help to anyone.

> Thanks, but I'm not a random bystander. Even if I were, I don't see
> how a compiled TODO for the distribution hinders development or
> rather, as seen in the previous thread, encourages discussion
> between developers.

Read http://www.livejournal.com/users/gravityboy/15401.html

In essence, this is akin to what Andrew Suffield calls "Voting
 for more money". A reasonable list of reasonable, achievabel goals
 for Etch is of real value. However, that requires thought, judgement,
 and triaging out marginal and unrealistic ideas out of the list; and
 that appears not to have been done.

> In any case, thanks for your constructive criticism. Ahem.

Well, I have said my piece, Feel free to ignore it.

manoj
-- 
Never call a man a fool.  Borrow from him.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Mon, 11 Jul 2005 10:29:46 +0100, Jochen Voss <[EMAIL PROTECTED]> said: 

> Hello Manoj,
> On Sun, Jul 10, 2005 at 08:30:57PM -0500, Manoj Srivastava wrote:
>> Yeah. I should have realized the level of audience I was trying to
>> talk to. I'll try to speak in words of fewer syllables the next
>> time around.

> You are actively damaging the project with remarks like this.
> Agression and unwillingness to play in a team are not helpful for
> us.  Please stop this!

And I think you are doing far worse by not giving short shrift
 to unworthy ideas and lack of critical analysis of views presented,
 but hey. Who is listening to anyone else any more?

manoj
-- 
Anything worth doing is worth overdoing.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Mon, 11 Jul 2005 10:17:56 +0100, Jochen Voss <[EMAIL PROTECTED]> said: 

> On Sat, Jul 09, 2005 at 08:33:42AM -0500, Manoj Srivastava wrote:
>> > 7. Fix up the all the silly typos made in every BTS email sent so
>> >far and retransmit. (note: this is after the BTS has decided
>> >to respond).
>> 
>> ! [1]
>> 
>> > 8. upload the changes to source code.
>> 
>> > 9. realize that I forgot to sign the upload due to a bug in by
>> >pbuilder wrapper script, create a *.commands file to send to
>> >the upload queue to delete the old upload and reupload again.
>> 
>> ! [2]
>> 
>> Are we sure we want someone who is routinely this incompetent to
>> help with bug triage? Seems to me we would be bette off without
>> such substandard help; anyone this incompetent is probably creating
>> more problems than they are solving.

> Great idea!  We can even get mor out of this, if we install some
> kind of challenge response system: every time you upload a package
> it mails you a set of three technical questions, and the upload is
> only permitted if all three answers are correct ;-) The same goes
> for the mail interface of the BTS of course.

Wonderful binary world you live in. If something can't be made
 dead simple, it is the same as making it as difficult as possible,
 eh?

Though the  idea does have merit. The distribution is groaning
 under the sheer size, and often substandard quality of packages; a
 measure like this may kill two birds with one stone.

manoj
-- 
Any sufficiently advanced technology is indistinguishable from a
rigged demo. Andy Finkel, computer guy
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jochen Voss]

Hello Manoj,

On Sun, Jul 10, 2005 at 08:30:57PM -0500, Manoj Srivastava wrote:
> Yeah. I should have realized the level of audience I was
>  trying to talk to. I'll try to speak in words of fewer syllables the
>  next time around.

You are actively damaging the project with remarks like this.
Agression and unwillingness to play in a team are not helpful
for us.  Please stop this!

Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Jochen Voss]

On Sat, Jul 09, 2005 at 08:33:42AM -0500, Manoj Srivastava wrote:
> > 7. Fix up the all the silly typos made in every BTS email sent so
> >far and retransmit. (note: this is after the BTS has decided to
> >respond).
> 
> ! [1]
> 
> > 8. upload the changes to source code.
> 
> > 9. realize that I forgot to sign the upload due to a bug in by
> >pbuilder wrapper script, create a *.commands file to send to the
> >upload queue to delete the old upload and reupload again.
> 
> ! [2]
> 
> Are we sure we want someone who is routinely this incompetent
>  to help with bug triage? Seems to me we would be bette off without
>  such substandard help; anyone this incompetent is probably creating
>  more problems than they are solving.

Great idea!  We can even get mor out of this, if we install some
kind of challenge response system: every time you upload a package
it mails you a set of three technical questions, and the upload is
only permitted if all three answers are correct ;-)  The same goes
for the mail interface of the BTS of course.

Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Javier Fernández-Sanguino Peña]

On Sat, Jul 09, 2005 at 08:25:11AM -0500, Manoj Srivastava wrote:
> This is a huge list, with probably 0 chances of getting
>  accomplished.  How about this: remove every single item from the list,
>  and only add items when there are people who sign up to be responsible
>  for the work involved in actually seeing that item come to fruition?

Errr.. the wishlists with names within brackets are those that have been
taken over by somebody, the ones that don't are up for grabs. This list is
meant as a stimuli for those that do not know what to do with their spare
time (yes, there's a number of DDs in that situation, believe me). 

Providing a list of things that need to be worked on, even if not Release
Critical, is a good thing IMHO. It is actually something we have been
lacking for previous releases in which the Release Goals were either
undefined or too vague. I find this list complementary with the pet release 
goals set for etch by the release team [1]

> Mere wishlists by random bystanders are no help to anyone.

Thanks, but I'm not a random bystander. Even if I were, I don't see how a
compiled TODO for the distribution hinders development or rather, as seen 
in the previous thread, encourages discussion between developers.

I don't know if the majority of developers thinks, like you do, that these
list is not useful at all. But I can bet you a beer or two that many of the
casual bystanders attending at Debconf5 were not even aware of the
relevance of some of the items in the TODO.

In any case, thanks for your constructive criticism. Ahem.

Javier

[1] http://lists.debian.org/debian-release/2005/06/msg00241.html


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>If this compromises their effectiveness, then they deserve
> every consequence of their laziness. A programmer being lazy does not
> mean sloppy, unprofessional, incompetence. I think you do not have a
> concept of what that statement was meant to convey in the first
> place -- laziness means that programmers automate away common tasks

however expecting a programmer to read docs does not mean it is ok to ship
outdated and confusing (example) config files. I had to track down the
correct upload queses multiple times (before dupload was fixed). This is
just awaste of time if it does not work with sane defaults.

bernd


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Sun, 10 Jul 2005 04:19:55 -0400, Kevin Mark <[EMAIL PROTECTED]> said: 

> On Sat, Jul 09, 2005 at 04:16:40PM -0500, Manoj Srivastava wrote:
>> On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen
>> <[EMAIL PROTECTED]> said:
>> 
>> > If these are good settings for dupload, why is it not included in
>> > the package as the default configuration for dupload?
>> 
>> Good by whose criteria? Yours? Mine? Joe random Developer's?  What
>> is more important -- speed, not seeing garbage on the screen when
>> uploading, or ensuring one always signs stuff? What if I use
>> pbuilder and it always signs stuff for me, so the check is just a
>> waste of time? What if I wanna upload even when linda crashes (as
>> it does periodically for me)?
>> 
>> 
>> Why are people so darned allergic to looking up the documentation
>> and configuring packages to suit their needs?  Why must one always
>> be spoon fed pap from the maintainer, straight out of the box, so
>> one does not ever have to think an iota for one self?

This posting is very incoherent, but I'll attempt a response
 anyway. 

> Hi Manoj, Read docs? Programmers are lazy, by design ;-)

If this compromises their effectiveness, then they deserve
 every consequence of their laziness. A programmer being lazy does not
 mean sloppy, unprofessional, incompetence. I think you do not have a
 concept of what that statement was meant to convey in the first
 place -- laziness means that programmers automate away common tasks

Indeed, the original poster was the antoithesis of the
 effective lazy programmer, for such a lazy programmer would never
 ever manually check that the packages were signed -- the lazy
 programmer would have used the mechanism I provided, or written their
 own coede to do so were it not possible already.

See, the lazy programmer shall spend hours coding away in an
 one time effort not to have to manually do a repetitice task over and
 over again -- something the OP failed to do.

> And if some programmer streamlines his/her debian programming tool
> workflow, would it not be advantageous if this was know?

How would your incompetent programmer ever know? The
 documentation already includes the  config details, which you
 evidently don't think people nbeed to read. If they don't read, how
 do you intend to convey these best practices to them? Sit on they
 chest and yell it into their ears as you pound their heads with a
 hammer? 

> While is may or may not be THE default, could it be put into
> /examples or noted in some dev-docs (or wiki.d.n)?


I see. You have no clue what is being talked about, and you
 just want to jump in to hear your own voice. What makes you think
 this is not documented? Ever looked at man dupload.conf ?

> Anyway to reduce errors like un-signed uploads is good, no?

You are prime example of why even documenting it, as it has
 been done, is not much help  at all.

> any way, happy hacking!  Kev

You realize your sig in 9 lines long, and has zero information
 content? It causes me usually to skip over your messages, since
 anyone rude enough to so blatantly ignore nettiquette rarely anything
 important to contribute.

Cut down your sig, and I would urge you to exercise brevity in
 your messages, unless you have something of substance to say.


manoj
-- 
Seek simplicity -- and distrust it. Alfred North Whitehead
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Kevin Mark]

On Sat, Jul 09, 2005 at 04:16:40PM -0500, Manoj Srivastava wrote:
> On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
> said: 
> 
> > If these are good settings for dupload, why is it not included in
> > the package as the default configuration for dupload?
> 
> Good by whose criteria? Yours? Mine? Joe random Developer's?
>  What is more important -- speed, not seeing garbage on the screen
>  when uploading, or ensuring one always signs stuff? What if I use
>  pbuilder and it always signs stuff for me, so the check is just a
>  waste of time? What if I wanna upload even when linda crashes (as it
>  does periodically for me)?
> 
> 
> Why are people so darned allergic to looking up the
>  documentation and configuring packages to suit their needs?  Why must
>  one always be spoon fed pap from the maintainer, straight out of the
>  box, so one does not ever have to think an iota for one self?
Hi Manoj,
Read docs? Programmers are lazy, by design ;-) And if some programmer
streamlines his/her debian programming tool workflow, would it not be
advantageous if this was know? While is may or may not be THE default,
could it be put into /examples or noted in some dev-docs (or wiki.d.n)?
Anyway to reduce errors like un-signed uploads is good, no?
any way, happy hacking!
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Mon, 11 Jul 2005 09:55:23 +1000, Brian May <[EMAIL PROTECTED]> said: 

>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED] (va, manoj)>
>> writes:
Manoj> ! [1]

: 7. Fix up the all the silly typos made in every BTS email sent so
:far and retransmit. (note: this is after the BTS has decided to
:respond).

> ???

The context, which is where your answer lies, is exactly what
 you elided. I guess that stands to reason. You routinely and
 consistently are unable to handle sending email?

Manoj> ! [2]

> ???

: 9. realize that I forgot to sign the upload due to a bug in by
:pbuilder wrapper script, create a *.commands file to send to the
:upload queue to delete the old upload and reupload again.

So, you can't read documentation to figure out how to make
 your uploader check that you have forgotten to sign things -- which
 also implies that your test/build/upload process leaves a lot to be
 desired, if this happens very often.

Manoj> Are we sure we want someone who is routinely this incompetent
Manoj> to help with bug triage? Seems to me we would be bette off
Manoj> without such substandard help; anyone this incompetent is
Manoj> probably creating more problems than they are solving.

> Are you implying that if I cannot write and maintain a pbuilder
> wrapper script that produces perfect results every time, regardless
> of regular interruptions, that I am incompetent?

Yes. This would be a bare modicum of competence,
 really. Building packages correctly and consistently is not rocket
 science. If you find it so, are you sure Gentoo is not more to your
 liking?

> You must be perfect!

Jesus Christ. I hope to hell you are kidding. Is sending email
 correctly, or crafting a build process so you do not forget to sign a
 sign of perfection? Is this wat the quality of the membership has
 deteriorated to?

Maybe /. is right after all. Perhaps Debian has grown too big
 to be a quality distribution, and we should all head over to Fedora
 Core 4.

> Which means the fact I could not have any definitions of [1] or [2]
> in your message must be my fault.  -- Brian May <[EMAIL PROTECTED]>

Yeah. I should have realized the level of audience I was
 trying to talk to. I'll try to speak in words of fewer syllables the
 next time around.

manoj
-- 
Are you making all this up as you go along?
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Brian May]

> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED] (va, manoj)> writes:

Manoj> ! [1]

???

Manoj> ! [2]

???

Manoj> Are we sure we want someone who is routinely this
Manoj> incompetent to help with bug triage? Seems to me we would
Manoj> be bette off without such substandard help; anyone this
Manoj> incompetent is probably creating more problems than they
Manoj> are solving.

Are you implying that if I cannot write and maintain a pbuilder
wrapper script that produces perfect results every time, regardless of
regular interruptions, that I am incompetent?

You must be perfect!

Which means the fact I could not have any definitions of [1] or [2] in
your message must be my fault.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Olaf van der Spek]

On 7/9/05, Manoj Srivastava va, manoj <[EMAIL PROTECTED]> wrote:
> On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
> said:
> 
> > If these are good settings for dupload, why is it not included in
> > the package as the default configuration for dupload?
> 
>Good by whose criteria? Yours? Mine? Joe random Developer's?
>  What is more important -- speed, not seeing garbage on the screen
>  when uploading, or ensuring one always signs stuff? What if I use
>  pbuilder and it always signs stuff for me, so the check is just a
>  waste of time? What if I wanna upload even when linda crashes (as it
>  does periodically for me)?

Wouldn't it be better to have a 'safe' default then a fast one?

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
said: 

> If these are good settings for dupload, why is it not included in
> the package as the default configuration for dupload?

Good by whose criteria? Yours? Mine? Joe random Developer's?
 What is more important -- speed, not seeing garbage on the screen
 when uploading, or ensuring one always signs stuff? What if I use
 pbuilder and it always signs stuff for me, so the check is just a
 waste of time? What if I wanna upload even when linda crashes (as it
 does periodically for me)?


Why are people so darned allergic to looking up the
 documentation and configuring packages to suit their needs?  Why must
 one always be spoon fed pap from the maintainer, straight out of the
 box, so one does not ever have to think an iota for one self?

What if there is no One True Way To Configure Everything?

The settings I provided suited the needs of the parent
 poster -- but may or may not suit the needs of everyone else (the
 linda afficianados would not like the settings, nor would people who
 always ensure their packages are signed by other means).

manoj
-- 
The bureaucracy is expanding to meet the needs of an expanding
bureaucracy.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Petter Reinholdtsen]

[Manoj Srivastava]
>> 4. Make dupload obsolete, and replace with dput. Make dput the
>>default in debrelease. I think dput would have prevented me
>>uploading my unsigned package.
> 
>  ~/.dupload.conf:
> $preupload{'changes'} = 'gpg --verify %1';
> $preupload{'sourcepackage'} = 'j=$(echo %1 | tr " " "_"); gpg --verify 
> "$j.dsc"';
> $preupload{'deb'} = 'lintian -v -i %1';
> 
> 
> Just this point (not knowing ones tools) makes this message
>  highly suspect.

If these are good settings for dupload, why is it not included in the
package as the default configuration for dupload?


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Sat, 9 Jul 2005 07:28:47 +0200, Christian Perrier <[EMAIL PROTECTED]> said: 

> Dunno which section of your list this should pertain but "Enforce
> the use of po-debconf for debconf templates" is in my mind.

> This probably needs a few s/SHOULD/MUST in the policy so that we can
> file RC bugs on packages which still use the "old style" debconf
> l10n system.

Why do we need to beat peope on the head with policy before
 they do this?  Could we have a list of people who are resisting this
 change? 

> There are few of these and, IIRC, none of them are really critical
> packages. Some work was done a few months ago, including NMUs, but
> the release priorities have stopped it.

Do you have a (perhaps partial) list f packages still using
 the old mechanism? An idea of the magnitude of the impact of this
 policy change would be helpful in deciding whether or not to change
 policy.

> I also think think about enforcing the use of debconf for packages
> during config step so that NO package prompts users outside debconf
> and interrupts installs/upgrades (wvdial comes to my mind).

It is not possible in all cases to ask all the questions
 before a package is unpacked.

manoj
-- 
"Mr. Spock succumbs to a powerful mating urge and nearly kills Captain
Kirk." TV Guide, describing the Star Trek episode _Amok_Time_
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Christian Perrier]

Dunno which section of your list this should pertain but "Enforce the
use of po-debconf for debconf templates" is in my mind.

This probably needs a few s/SHOULD/MUST in the policy so that we can
file RC bugs on packages which still use the "old style" debconf l10n
system.

There are few of these and, IIRC, none of them are really critical
packages. Some work was done a few months ago, including NMUs, but the
release priorities have stopped it.

I also think think about enforcing the use of debconf for packages
during config step so that NO package prompts users outside debconf
and interrupts installs/upgrades (wvdial comes to my mind).



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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

On Sat, 09 Jul 2005 20:13:57 +1000, Brian May <[EMAIL PROTECTED]> said: 

> 1. Review bugs in web browser.
> 2. Identify questionably bug that you haven't already looked at
>before today.

Hint: have a local notebook that you mark bugs you look at.

> 3. Inspect bug report, in new window, install package, install
>source, inspect as required. Open up new browser windows to find
>information as required.

There is a download bug reports as mailbox feature.

> 4. Make changes as required to source code.
> 5. Enter one/more emails to either forward bug upstream, change
>tags, or close the bug.
> 6. Go back to step 3.

> 7. Fix up the all the silly typos made in every BTS email sent so
>far and retransmit. (note: this is after the BTS has decided to
>respond).

! [1]

> 8. upload the changes to source code.

> 9. realize that I forgot to sign the upload due to a bug in by
>pbuilder wrapper script, create a *.commands file to send to the
>upload queue to delete the old upload and reupload again.

! [2]

Are we sure we want someone who is routinely this incompetent
 to help with bug triage? Seems to me we would be bette off without
 such substandard help; anyone this incompetent is probably creating
 more problems than they are solving.

> 4. Make dupload obsolete, and replace with dput. Make dput the
>default in debrelease. I think dput would have prevented me
>uploading my unsigned package.

 ~/.dupload.conf:
$preupload{'changes'} = 'gpg --verify %1';
$preupload{'sourcepackage'} = 'j=$(echo %1 | tr " " "_"); gpg --verify 
"$j.dsc"';
$preupload{'deb'} = 'lintian -v -i %1';


Just this point (not knowing ones tools) makes this message
 highly suspect.

manoj
-- 
Only the hypocrite is really rotten to the core. Hannah Arendt
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Manoj Srivastava]

Hi,

This is a huge list, with probably 0 chances of getting
 accomplished.  How about this: remove every single item from the
 list, and only add items when there are people who sign up to be
 responsible for the work involved in actually seeing that item come
 to fruition?

Mere wishlists by random bystanders are no help to anyone.

manoj
-- 
A gift of flower will soon be made to you.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Brian May]

> "Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:

Santiago> Well, I consider the idea that old bugs deserve more
Santiago> attention than new bugs (or non-old bugs) completely
Santiago> flawed.

I wonder how many old bugs are either fixed (but not marked as fixed)
or irrelevant (if another solution was used).

I suspect that there would be a high percentage of such bugs.

Santiago> Bugs do not increase their severity by age. A wishlist
Santiago> bug which is ten years old is still a wishlist bug. A
Santiago> normal bug which is ten years old is still a normal
Santiago> bug. An important bug which is ten years old is still an
Santiago> important bug (well, modulo the fact that the important
Santiago> severity might not exist ten years ago :-).

True. However, I think it is easy to forget about old bugs and
concentrate only on the new.

After all who wants to spend considerable time gong over old bugs,
attempting to work out if they are still relevant, for situations that
you are never likely to encounter yourself, when you could be fixing
"real" problems (as in problems that effect you)?

Maybe the process of reviewing old bugs could be improved. I find the
current process very clumsy:

1. Review bugs in web browser.

2. Identify questionably bug that you haven't already looked at before
   today.

3. Inspect bug report, in new window, install package, install source,
   inspect as required. Open up new browser windows to find
   information as required.

4. Make changes as required to source code.

5. Enter one/more emails to either forward bug upstream, change tags,
   or close the bug.

6. Go back to step 3.

7. Fix up the all the silly typos made in every BTS email sent so far
   and retransmit. (note: this is after the BTS has decided to
   respond).

8. upload the changes to source code.

9. realize that I forgot to sign the upload due to a bug in by
   pbuilder wrapper script, create a *.commands file to send to the
   upload queue to delete the old upload and reupload again.

It would be good if this process could be simplified and/or made more
error resistant. For example:

1. Client program that lists all bugs and has the ability to mark
   bugs. Ability to sort bugs in order of when you last looked it one.
   This information should be stored on maintainers computer, not the
   BTS.

   Even better, if you could attach a short summary/note to each one
   for your use, e.g. "need to talk to XYZ about this", "this user is
   an idiot", "I think this has been solved but I need to check X
   first", or "as of 1/1/2005 this bug is still waiting on X" that
   you don't want to appear in the BTS. This should be immediately
   visibly without having to select the bug and scrolling to the
   bottom.

   This way you can get a clear picture of which bugs require
   immediate attention, and which bugs you consider "too-hard" or
   "too-time consuming" right now, or are waiting on other outside
   events.

2. Client program with provision for sending updates to the BTS, but
   caching the updates until they finally appear in the BTS. Either
   that or fast response time from the BTS.

3. Environment/scripts to enable better testing, updating, and
   recompiling packages even if it is based on a non-preferred
   distribution, e.g. if you use stable, but the bug report is against
   unstable or vice versa.

   pbuilder is good and building packages against other distributions,
   it is not so good (at the moment anyway) for testing arbitrary
   packages in arbitrary distributions (except via pre-written
   scripts), because it was designed for building not interactive
   testing. There is the "pbuilder login" operation, but it doesn't
   give you access to your newly created package.

4. Make dupload obsolete, and replace with dput. Make dput the default
   in debrelease. I think dput would have prevented me uploading my
   unsigned package.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Steve Langasek]

On Fri, Jul 08, 2005 at 03:49:36PM +0200, Santiago Vila wrote:

> On Fri, 8 Jul 2005, Javier Fernández-Sanguino Peña wrote:

> > [...]
> > - Remove _all_ out of date dummy packages! (see #308711 and other bugs!)
> >   Note: Almost done by ftp-masters, some pending and needs to be reviewed
> >   to remove woody->sarge which are not applicable to ->etch

> IMHO, we should keep dummy packages around for at least two releases,
> to support upgrades which skip one release.

In practice, upgrades that skip a release are not supported.  There was no
way at all that upgrades from potato->sarge could have been supported, and
it's not a goal of the release team to support direct upgrades from
woody->etch.

So keeping these dummy packages around is simply needless overhead, IMHO,
both in the archive and in the Packages files.

> Instead of a crusade against dummy packages (some of which are not old
> enough so that removing them does any good), I would like to see a
> crusade *for* dummy packages, so that a package which changes name
> without a dummy package is considered a RC bug and we are forced to
> fix it

While I don't think the release should block on having dummy packages for
all such upgrades, I certainly agree quite strongly that maintainers should
be doing whatever possible to support automated upgrade paths in these
cases.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Marco d'Itri]

On Jul 08, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> * was far too fragile, with races all over the place which make some
>   things work correctly some of the time and not at all on the next
>   reboot,
The solution to these problems is to use RUN rules (what once were dev.d
scripts).

> * requires way too much configuration for a system which only exists to
>   access my hardware, with documentation in /usr/share/doc/udev which
>   blatantly states that some things *will not* work out of the box, and
>   *will* require you to manually configure stuff.
With the recent serio and ieee1394 sysfs kernel fixes all the common
situations should be handled correctly with the exception of
non-autostarted RAID volumes.
(Other distributions ship udev by default, so it can't be so bad...)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Josselin Mouette]

Le vendredi 08 juillet 2005 à 14:40 +0200, Marco d'Itri a écrit :
> On Jul 08, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:
> 
> > Feel free to add any other wishlists (or discuss any one of them). I'll try 
> > to track the subsequent thread and keep the list current somewhere...
> Make hotplug depend on udev (this simplifies a lot the hotplug scripts).

But... but... that's a circular dependency !
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Wouter Verhelst]

On Fri, Jul 08, 2005 at 07:07:20PM +0200, Marco d'Itri wrote:
> On Jul 08, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> 
> > > > Feel free to add any other wishlists (or discuss any one of them). I'll 
> > > > try 
> > > > to track the subsequent thread and keep the list current somewhere...
> > > Make hotplug depend on udev (this simplifies a lot the hotplug scripts).
> > No you don't.
> If you really feel strongly about this then you will have to provide
> some arguments too, considering the higly positive side effects that
> such a change would have (and that at some point in the future udev will
> be mandatory anyway).

This was said about DevFS too, when it was introduced.

My gripe with udev is that, last I tried, it
* was far too fragile, with races all over the place which make some
  things work correctly some of the time and not at all on the next
  reboot,
* requires way too much configuration for a system which only exists to
  access my hardware, with documentation in /usr/share/doc/udev which
  blatantly states that some things *will not* work out of the box, and
  *will* require you to manually configure stuff.

In contrast, static /dev stuff Just Works. It might not have the same
features as udev does; but what it does, it does well, with next to *no*
configuration and *no* races.

Of course, if the situation has been improved since, so much the better;
but 'last I tried' was only two months ago, IIRC.

In that light, I urge you not to make udev usage mandatory for hotplug
in the near future. If the problems with udev are fixed (in that the
races are gone and stuff will just work out of the box), then perhaps.
Not just yet.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Marco d'Itri]

On Jul 08, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> > > Feel free to add any other wishlists (or discuss any one of them). I'll 
> > > try 
> > > to track the subsequent thread and keep the list current somewhere...
> > Make hotplug depend on udev (this simplifies a lot the hotplug scripts).
> No you don't.
If you really feel strongly about this then you will have to provide
some arguments too, considering the higly positive side effects that
such a change would have (and that at some point in the future udev will
be mandatory anyway).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Wouter Verhelst]

On Fri, Jul 08, 2005 at 02:40:55PM +0200, Marco d'Itri wrote:
> On Jul 08, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:
> 
> > Feel free to add any other wishlists (or discuss any one of them). I'll try 
> > to track the subsequent thread and keep the list current somewhere...
> Make hotplug depend on udev (this simplifies a lot the hotplug scripts).

No you don't.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Olaf van der Spek]

On 7/8/05, Santiago Vila <[EMAIL PROTECTED]> wrote:
> Sure, old bugs may be the symptom that the maintainer is MIA, that the
> upstream maintainer is MIA, and similar things that we should of
> course track as well, but it does not mean that an old bug is "worse"
> in any way than a new bug (eveything else being the same).

What's the proper way to deal with maintainers that kinda 'ignore'
bugs (in whatever way)?

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Santiago Vila]

I'm going to disagree with two points here.

On Fri, 8 Jul 2005, Javier Fernández-Sanguino Peña wrote:

> - _No_ bugs in base packages (well, at least no old bugs). Base system
>   should be upgraded to latest upstream (forward patches!) this includes
>   PAM, modutils...
>  * Base packages should be co-maintained and maintainers should be
>  open to help (not always the case currently)
> 
> - Review and fix or remove very old bugs:
> http://master.debian.org/~ajt/oldbugs.html

Well, I consider the idea that old bugs deserve more attention than new
bugs (or non-old bugs) completely flawed.

Bugs do not increase their severity by age. A wishlist bug which is
ten years old is still a wishlist bug. A normal bug which is ten years
old is still a normal bug. An important bug which is ten years old is
still an important bug (well, modulo the fact that the important
severity might not exist ten years ago :-).

While it would be a nice thing not have "old" bugs, it would be even
nicer not to have important bugs, for example, so I think we should
not chase "old" bugs because of them being old.

Sure, old bugs may be the symptom that the maintainer is MIA, that the
upstream maintainer is MIA, and similar things that we should of
course track as well, but it does not mean that an old bug is "worse"
in any way than a new bug (eveything else being the same).

> [...]
> - Remove _all_ out of date dummy packages! (see #308711 and other bugs!)
>   Note: Almost done by ftp-masters, some pending and needs to be reviewed
>   to remove woody->sarge which are not applicable to ->etch

IMHO, we should keep dummy packages around for at least two releases,
to support upgrades which skip one release. We can't argue that they
are difficult to maintain, or that they take a lot of space in the
archive.  Sure, we can't test upgrades which skip one release as much
as normal upgrades, but if we know for sure that an upgrade will *not*
be smooth when there is a missing dummy package, we do not even have
to test the upgrade to know that it will fail, and there is no point
in gratuitously and knowingly breaking the upgrade.

Instead of a crusade against dummy packages (some of which are not old
enough so that removing them does any good), I would like to see a
crusade *for* dummy packages, so that a package which changes name
without a dummy package is considered a RC bug and we are forced to
fix it (see Bug#196390 for an example of bug which I think we should
not have released sarge without fixing it).

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Marco d'Itri]

On Jul 08, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:

> Feel free to add any other wishlists (or discuss any one of them). I'll try 
> to track the subsequent thread and keep the list current somewhere...
Make hotplug depend on udev (this simplifies a lot the hotplug scripts).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

"How to recognise different ETCH wishlists from quite a long way away" (revised)

[Javier Fernández-Sanguino Peña]

Well, since the thread I started has calmed down and since there's a lot of 
people at HEL [1] with (probably) a lot of spare time in their hands that 
would be better spent hacking than in the sauna here's my (revised) 
wishlist for Etch.

I've added additional items pointed out in the thread (including who 
"claimed" them) as well as some new stuff. This wishlist is not necessarily 
(sp?) aligned with the Etch Release Goals [2] it probably has more "pets" 
but, if you have spare time to work on any of these items I'm sure that the 
whole Debian community will appreciate it!


TODO: Add information from previous (older)  discussions at
   http://lists.debian.org/debian-devel/2003/08/msg02243.html
   or 
   http://lists.debian.org/debian-devel/2002/05/msg02497.html
TODO: Should this be in   http://wiki.debian.net/index.cgi?ReleaseProposals ?

[ Overall improvements ]

- _No_ bugs in base packages (well, at least no old bugs). Base system
  should be upgraded to latest upstream (forward patches!) this includes
  PAM, modutils...
 * Base packages should be co-maintained and maintainers should be
 open to help (not always the case currently)

- Review and fix or remove very old bugs: 
http://master.debian.org/~ajt/oldbugs.html

- Updates to base packages: many base packages are in a bug-fix only cycle,
  we are mostly doing a very good job keeping up-to-date with upstream
  but some need to be updated and might introduce major changes. 
  Example:
Package  Current Upstream  Bug
pam  0.76-22 0.79  #284954
cron 3.0pl1-87   4.1   -
dhcp 2.0pl5-19.1 3.0.2 [None, dhcp3 package available]
  [jfs] Will work on cron (co-maintain) and already provided new pam packages 
to 
  the Debian maintainer.

- [rfrancoise] Libpcap0.9 transition
- [doko] Toolchain update to gcc/g++ 4.0 

- Review patches developed by other distros to base packages. Many of the
  bug fixes / improvements there apply to us too.
  Note: The fact that Fedora's CVS is now open helps in this quite a lot
  Other that should be reviewed include OpenBSD's CVS and Mandrake source RPMs.
  [jfs] Doing so for pam and cron

- Implement some package reorganizations that have been postponed over
  several releases; example:
  #100332: tetex-bin: please move xdvi to its own package

- [rleigh] Transition to UTF-8 locales
  Message-ID: <[EMAIL PROTECTED]>
* The locale codeset could be UTF-8 for some new installs by default
  (depending on locale?)
* Existing installations should be unaffected, but it might be nice to
  offer to generate the equivalent UTF-8 locales for the locales in use.
  Also see #99933 and #99324?

- [joss] Drop libpng2/libpng10-0/libpng3 packages 
- [adconrad] Drop libmysqlclient10/libmysqlclient12 packages 
- [vorlon] Consistent LFS support
- [zobel] IPv6 readiness: make sure all packages support IPv6 completely
- [ballombe] Get rid of circular dependancies
- [jfs] Get rid of useless dummy packages (pending review of the find-dummies
  script result)

[ Installation improvements ] 

- Firewall configuration during installation (ala Fedora Core or SuSE):
  module for d-i. Currently, the system is exposed just during installation
  on some systems (empty root password?)
* [joeyh] D-i needs to protect the system
* [joeyh] Firewall task in d-i?

- Reduced standard installation (no gcc or development tools!, see 
  #301138 or #301273)
* [joeyh] Will happen with a new d-i 'standard' task (selected by default)

- More "tasks" (grouped packages) for installation: automatic detection
  of user needs and automatic task selection?
* [joeyh] Will be added to tasksel, help needed0

- Encrypted root/swap on the d-i installation.
- Booting from the d-i and not need a reboot ?


[ Security improvements ] 

- Proper signature detection (apt-secure, currently on experimental)
- ExecShield or PaX in stock kernel - buffer overflow protection
- SELinux support - Mandatory Access Control (RSBAC?)
- Possibility to recompile the distro with SPP (apt-build?). New
  i386-spp architecture?
- Proper source code audit by maintainers to detect stupid security
  bugs (/tmp/XX.?? anyone?) Recurrent things like #306893 appear all
  too often. Automatic source code audit ala lintian.debian.org? 
- MD5 / SHA-1 listing of files in ftp sites (useful for forensics analysis
  see #303961)
- [zobel] Packages should document what should be added to
  hosts.{allow,deny} if using tcp-wrappers

- (policy) Only support a subset of our current packages, meaning to support
  the full archive when there's so many things is insane, does not scale
  and is against us. Better do what *BSD do explicitly (ports are supported
  in a "best effort basis") or what others do implicitly (distros with less
  packages provide less security support). Maybe introduce a priority between
  standard - optional to include non-standard packages that are security
  supported ('common'?) or