[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DPLs : what do you think about ...



On Sun, Dec 13, 1998 at 12:42:41PM +0100, Raphael Hertzog wrote:
> the choice beetween the possible DPLs is very difficult. I like
> Ben Collins's ideas, I like Joseph Carter's enthusiasm and I like Wichert's
> experience. :-)

Thank you, I am sure I can safely speak for us all when I say we
appreciate it.


> That's why I would like to know who will support some projects, and who will
> do the necessary so that they'll become reality. Here are the projects
> I would like to see achieved :

Speaking just for me again...


> - Ben Collins idea : no unstable fork before deep-freeze

There are problems with this which others have been discussing.  I've
been entertaining ideas in my own head about this type of problem
suggested by others.  I'm not opposed to some sort of change in this
regard, but I dislike exactly this change for a number of reasons already
presented by others.  If we're going to go tinkering with release
mechanics, let's do it right the first time if possible.


> - creation of a "Bug Group" who could manage the Bug Database without fearing
>   a maintainer blame. This group should manage "important" and "critical"
>   bugs not only during freeze but also while beeing in unstable... in this 
>   way when the freeze start, there won't be to much release-critical bugs.
>   This group could also organize "bug's party" on IRC in order to
>   clean up the BTS of a specific package (like it has already be done
>   for ppp).

Wichert:  I know you have automated this, is it possible for you to have
things track bugs in both frozen and unstable or would this require
extensive modification of the BTS to accomidate you?

This may or may not be possible to track bugs in unstable AND bugs in
frozen anytime soon.  If it can be done, I think it'd be a good thing. 
It's kinda up to Wichert though.

Organizing groups to tackle bugs one way or another should probably be
handled on an individual package basis.  Some developers will get
understandably annoyed if someone starts messing with their package
without talking to them first.


> - APT beeing finished :-)

This is really up to the apt team.  As an apt user myself, I'm itching to
see their work.  I'm not sure what the DPL can do for them other than if
the DPL is a good coder and has time offering to help.  =>


> - Configuration management with internationalization support (I didn't speak
>   of that but I wanted to...)

Instead of asking who wants to support this, it might be easier to ask
who does NOT support it.  => If I were to attempt to herd the cats any
direction, this would be it.


> - Simplification of the installation (enhanced boot disks)...

Hopefully as part of the above two.  =>


> The one who will support all this will have my vote :-) And "support" does
> mean : do the right things in order to achieve them... ;-)

Do the right things how?  Just start coding?  Making suggestions to the
people working on these things how they might make them better?  Working
with the three teams to help coordinate their group efforts and help see
the things be integrated?  These last three points are very much team
efforts and there are already teams working on them.

The first I don't support.  I will support a change to the archive if the
change actually clears up some of the problems.  This would not be such a
good chnage in the long run, it wouldn't even really do what it would be
intended to do very nicely.  =<

Monitoring the critical bugs throughout the development cycle, adding
release notes, organizing bug-squish-a-thons and that sort of thing leads
to interesting ideas.  Another area I'm interested in, but whatever
alterations are made should be made to fix the problems and do things
better than we are.  I don't like change for the sake of change much.

-- 
"Shall we play a game?"  -- WOPR


Reply to: