Re: Release
> > I told you in the beginning that you cannot give responsibility without
> > also giving authority. As project leader you of course have final say on
> > everything that happens. But, as president of my own company, I can tell
> > you that exercising such authority is generally not a good idea.
>
> That's why I held off as long as possible. Possibly too long.
I can be a stubborn S.O.B. Just ask the guys I work with. But while
I will fight hard for what I believe in, I like to think of myself as
a resonable guy when people try to reason with me instead of just
fighting against me.
If you had a concern, you should have come to me in private and said
"I think we should do this, and this is why", we could have discussed
it. But, in the end, if we still disagree, you should let me do it
the way I say. It is _my_ job. Unless you plan to do everything
yourself, you have to let those you put in charge to do things the
way they see fit.
> > I made mistakes in doing this too. The "code freeze" was supposed to
> > be the start of the beta testing. I should have annouced this as
> > official beta, but I didn't.
>
> You also didn't have all of the pieces in place at the time of the code
> freeze.
The only piece I'm aware that was missing is the base disks. I didn't
even know they were missing until early this week. I've already chalked
that up on my list to check next time. If there is more I missed, please
let me know.
> > Rex works as it is.
>
> Except that cold installs don't work too well. Upgrades work great.
A perfectly valid (IMO) reason to slip the date. However, until this
moment, I did not know this. Nobody told me. As you well know, Debian
is too big a beast to be fully monitored by one person.
> > Adding X3.2 will just delay it by at least a month.
>
> I was hoping that would not be the case. How many shared library
> dependencies need to be changed? Can we provide a stub package to link
> the old dependency names to the new ones? Do packages linked to 3.1 not
> work with the libraries in 3.2?
I really hate shipping "hacks". My personal experience is that they
cause more problems than they solve.
> > If you don't want me to manage the distribution, then just say so and
> > I'll resign. Just let me know one way or the other. But, coming to me
> > on the last day to say "delay it because..." just isn't acceptable.
> > Nobody even _asked_ me.
>
> Don't resign. Do be willing to bend. I would not have taken any action
> except that it was clear that some responsible people were screaming for
> action. You have a few real show-stoppers in 1.2 . At least one real serious
> security bug, in the core of X, not in a package that we can dispense with,
> and some stuff that needs more testing. At that point, the clock takes second
> priority to delivering a product that won't ruin your reputation. So please
> help chart what we are going to do now, and let me deal with our public
> perception.
I am willing to bend, but I am logical to the core. Adding functionality
(eg. shadow passwords) or fixing what I consider to be non-critical bugs
(eg. X security hole) are not, in my opinion, valid reasons to change my
stand on an issue.
Actually, to be fair, I think the X problem is a big one. It's just that
my instincts tell me that fixing it for Debian 1.2 will take long enough
that the difference between release 1.2 as is and releasing 1.3 with the
new X will be quite minor and thus the benefits gained from such do not
outweigh the costs associated with slipping.
Now, you tell me that 1.2 does not install very well. How can I help?
How long will this take to fix? Which packages need more testing? Again,
nobody told me.
I'm willing to stay on as "Distribution Manager", but I need some
concessions, too. I will do my absolute best to create a solid, working
distribution for people. I will try to be more flexible and I will take
the heat for my mistakes. For this reponsibility, though, I need
authority to implement it. What I need is final say on what does or does
not go into a distribution and when a distribution gets released. I do
not expect everybody to like my decisions all the time. I do expect people
to respect those decisions.
So, all that being said, I need more information on what is wrong
with Rex as it stands.
Since Rex has to slip for other reasons, I am more open to including
the newest X.
As a quick schedule, then:
- 2 weeks to bring the new packages (X & Shadow) over to Rex
- 2 weeks for Christmas (during which little will get done)
- Rex will freeze again for 4 weeks (public "beta")
- Rex will release as "Debian 1.2" for February 1st.
This should give plenty of time to fix and "cold install" problems
with Rex as well as get the new base disks in line. This puts us
two months behind the original plan, but that isn't really as much
time as it sounds. It is really only 6 weeks of workable time and
while it could probably be shortened to 4 weeks (mid-Jan), I
do not think it would be worth it. If you're going to do something,
you might as well do it right.
If this sounds acceptable to people, I will put together an
announcement for debian-announce and comp.linux.announce about the
change in release dates.
Brian
( bcwhite@verisim.com )
-------------------------------------------------------------------------------
Searching for something? Look to us! http://www.verisim.com/ferret/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: