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

Re: I cant be that professional... you eighter (was: Bug#118388: intent to NMU merlin-cpufire)



* Bernd Eckenfels <lists@lina.inka.de> [2001-11-06T21:35+0100]:
> On Tue, Nov 06, 2001 at 03:58:04PM +0100, Michael Weber wrote:
> >  Firstly, the acceptable waiting period - the time between when the
> >  bug is submitted to the BTS and when it is OK to do an NMU - is seven
> >  days for porters working on the unstable distribution.

Note: I didn't express my own opinion above, I merely quoted the DDR.
      Please, be careful when quoting.

> A only if it is a in any way 'important' package (means: anything is
> depending on it or it is an standard package or corruption is fatal for
> users) it is justified to NMU within less than 10 days.

Fine, that's your opinion.  Since GRs are popular these days, start
one (or do whatever is needed), and try to change the guidelines. ;)
But think of reasons why it is like it is, for which reasons it should
be changed, and what effects this may have eventually.

And, please, understand that porters usually deal with loads of
packages per day.  Every day.  And depending on the architecture,
quite some of those fail to build for some reason or another, which
means even more work.  And sometimes it's true that maintainers are
not that responsive, for whatever reasons...

After some time spent on porting, at least I tend to start treating
all packages the same, regardless of how important they are. And how
am I supposed to know this, maybe they're important to someone else...

> I will be pissed off if anybody is NMUing a package of mine in less than 2
> weeks. And I mean it will immediatelly ITOed.

Porters are allowed to do so for a reason.  AFAIK, if an architecture
falls behind for more than 10%, it's regarded as not in releasable
state (somebody correct me, if I'm wrong here).  Here, those
'unimportant' packages are /not/ handled differently.

Also, (although it doesn't apply in this particular case) those
packages which are broken on at least one arch that counts, won't go
into testing as soon as they could go, if at all, as you undoubtedly
know.

And just to give you some more numbers: last I checked there were ~160
broken packages for the powerpc architecture.  They have to be dealt
with...  and everyday new versions of packages are uploaded, and while
dealing with porting work, I didn't have a single day until now
without broken packages.  Now, go figure...

> I do no longer enjoy working for Debian under those kind of pressure and I
> do not think you will find a lot of volunteers which can keep up with that
> kind of strict time restrictions.

Geez, I cannot understand why people are so anal about the packages
they're maintaining.  They are not exactly your property! 

If someone thinks he can do a better job maintaining my packages and
gives me enough evidence to believe that person, I'll happily step
down, hand over my packages, and move on to other things.

If someone breaks packages, that's a different story, but we are all
human (well, most of us, anyway... ;)).  Shit happens.  It shouldn't
happen more than once, so I'ld try hard to not let such a situation
arise again and make sure the one who's responsible learns from that.
If that doesn't help, and we can't settle on an agreement, I would
bring up the issue to the Technical committee.  It's there for a
reason.

Besides, Overfiend has a tendency to "accelerate" actions (sometimes
by drastic means ;)), but in the end, the users profit from that in
one way or another...

Note, that I don't want to attack either you (Bernd) or Branden, and
maybe this doesn't make too much sense at all (since I'm tired and
overworked), but my main points are

1) I don't like people bitching about "their" packages, because they
   aren't, IMHO.

2) If the user gets higher-quality packages, fine. (Remember, it's all
   about the users...  I get the impression that we tend to forget
   that far too often...)


Cheers,
Michael "anyone wants my packages? :)" Weber



Reply to: