Thoughts on Debian quality, including automated testing

classic Classic list List threaded Threaded
86 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Thijs Kinkhorst
On Thu, 2005-12-22 at 08:38 +0000, Andrew Suffield wrote:
> On the other hand, I think there might be some benefit to requiring
> that the Maintainer field must always denote one single Debian
> developer, who would be the "buck stops here" guy for that
> package. Not an applicant, not a mailing list, and not a group of
> people.

This "not an applicant" thing is a bad idea. As you might know, the
NM-process is designed around the idea that someone has to prove they're
up to the task they want to do. That's why for packagers it's required
to have packaging activitity. Disallowing them to have the final
responsibility over a package disables you to evaluate whether they're
actually fit for this responsibility. In the current situation, it's
already clear that the person in the Maintainer field has the final
responsibility, and the sponsor acts as a fallback only.


Thijs

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Frank Küster
In reply to this post by Thomas Hood-6
Thomas Hood <[hidden email]> wrote:

> Under most of these topics Lars discussed automated testing.  Are
> there objections to Lars's concrete proposals (e.g., standardization
> on a way to invoke package specific tests)?  Are there other ideas?
> Should Debian do more auditing, for example?

I'm all for automated testing, but I want to support Lars' point that
the burden should be mostly on the people writing the automatisms, not
on individual package maintainers reinventing the wheel.

> Then what other things
> can be done to help individual maintainers fix more bugs and fix them
> better?

It would be good if there was a way to find out "problematic" packages,
by extracting information about

- how many bugs does a package have

- how many of them don't have a single response

- how many have not been dealt with for n months (or days/weeks for RC
  bugs)

- how many packages depend on the package

and try to create some rating or ordering.  One could then not only
identify packages that could use some work, but also for which of them
it's most useful.

Another good thing would be an effort to go through important packages'
ancient bugs and clear them up.  E.g. all those, mostly years-old dpkg
bugs that report a segfault.  Either something should be done about
them, or they should be closed.  My impression is that dpkg is actively
maintained currently, but had some problems in the past, and the current
maintainers don't have the time to clean up this inherited mess.  It
seems to me that this is a problem in other packages, too.  teTeX is one
of them...


Regards, Frank


--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Adrian von Bidder
In reply to this post by Andrew Suffield
On Thursday 22 December 2005 09.38, Andrew Suffield wrote:
> On the other hand, I think there might be some benefit to requiring
> that the Maintainer field must always denote one single Debian
> developer, who would be the "buck stops here" guy for that
> package. Not an applicant, not a mailing list, and not a group of
> people. I believe the tools have now advanced to the point where this
> is a practical option.

Now that's an idea I like.

-- vbi

--
Vote for me.  You may not agree with me, but at least I understand
what's going on
        -- steevo in news.admin.net-abuse.email

attachment0 (398 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Adrian von Bidder
In reply to this post by Thomas Hood-6
Thomas, sorry for continuing the debate still on this single aspect of Lars'
mail :-)

On Thursday 22 December 2005 10.02, Thomas Hood wrote:
>     C) Fix bugs that have been reported
> For C, Lars discussed different degrees of shift from solitary toward
> collective maintainership.  In the sequel opinions were emphatically
> expressed that such a shift is not necessarily a good thing.

Hmm.  AFAICS The strongly voiced opinions have only opposed to the *force*
team maintainership thing.  That team maintainership *when the maintainers
want it* is a good idea and should probably be encouraged has not been
debated.  There was some argument whether team maint of trivial, small
packages makes sense and there was Frank's statement about large-scale
teams which I completely agree with.

cheers
-- vbi

--
The prablem with Manoca is thot it's difficult ta tell the difference
between o cauple af the letters.
        -- Jacob W. Haller on alt.religion.kibology

attachment0 (398 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Adrian von Bidder
In reply to this post by Frank Küster
On Thursday 22 December 2005 10.55, Frank Küster wrote:
> - how many bugs does a package have
> - how many have not been dealt with for n months (or days/weeks for RC
>   bugs)

Changing the default ordering on the bts web pages from bug age to 'last
action age' might already show some effect.

Hmmm.  But it'd make the ordering much more volatile.  So maybe bad idea?  
But at least displaying time since last update alongside the age of the bug
might make sense.

-- vbi

--
It works! Now if only I could remember what I did...

attachment0 (398 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Petter Reinholdtsen
In reply to this post by Russ Allbery-2

[Russ Allbery]
> Also, I think this is a little silly for small packages.  My
> experience with this sort of volunteer work in other areas is that
> if one person does nearly all the work on a regular basis, you're
> not gaining that much by having a backup.  The person who is
> theoretically the backup isn't up to speed on the package anyway and
> is going to be starting roughly as cold as any other random person
> out there.

Did you miss the point that a package need to rot quite a long time
before packages are taken out of the hands of a missing or useless
maintainer?  If there is a co-maintainer, he will most likely not wait
that long before he continue maintenance of the package.

You seem to be talking about a "co-maintainer" whose entire
responsibility is to be listed in the uploaders field, while I talk
about co-maintainers which have expressed interest in actually
maintaining a package.  The latter are quite likely to be able to take
over when the primary maintainer us unable to keep up with his tasks.


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

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Daniel Ruoso
In reply to this post by Raphael Hertzog-3
Em Qui, 2005-12-22 às 10:22 +0100, Raphael Hertzog escreveu:
> On Wed, 21 Dec 2005, Daniel Ruoso wrote:
> > Maybe it would be interesting to have some information in the package
> > saying how the package is managed and the preferrable way of doing an
> > NMU (I actually, think that it's desirable to self-include in the
> > Uploaders field, to acquire responsability also)...
> In the PTS, I'd like to be able to point people to the CVS/SVN/arch
> repository used by the maintainers, however I can't because the
> information is not stored, or is stored in a non-formal manner in
> README.Debian.

Hmmm... You probably pointed out the best way to achieve that... If you
look carefully, you'll see that the PTS uses informations that are
spreaded around several subsystems...

So, the nicest way is to create yet another subsystem that would manage
this type of information, and once many people starts putting
information there, the PTS will include it also...

daniel


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

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Russ Allbery-2
In reply to this post by Petter Reinholdtsen
Petter Reinholdtsen <[hidden email]> writes:
> [Russ Allbery]

>> Also, I think this is a little silly for small packages.  My experience
>> with this sort of volunteer work in other areas is that if one person
>> does nearly all the work on a regular basis, you're not gaining that
>> much by having a backup.  The person who is theoretically the backup
>> isn't up to speed on the package anyway and is going to be starting
>> roughly as cold as any other random person out there.

> Did you miss the point that a package need to rot quite a long time
> before packages are taken out of the hands of a missing or useless
> maintainer?

Maybe that's the problem that you should concentrate on fixing instead of
trying to work around it with a solution that won't necessarily fix it and
which adds pointless overhead to packages that are well-maintained?

> If there is a co-maintainer, he will most likely not wait that long
> before he continue maintenance of the package.

Or maybe he'll be so uninterested in the package since there's never been
anything for him to do that he won't even notice the problem and won't be
any improvement over not having a co-maintainer at all.

> You seem to be talking about a "co-maintainer" whose entire
> responsibility is to be listed in the uploaders field, while I talk
> about co-maintainers which have expressed interest in actually
> maintaining a package.  The latter are quite likely to be able to take
> over when the primary maintainer us unable to keep up with his tasks.

I'm pointing out that if you require co-maintainers for small packages,
what you're going to get is a whole bunch of the former.  There isn't
enough work for two people, plus people annoyed with the rule will list
co-maintainers in order to make people stop bugging them.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


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

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Russ Allbery-2
In reply to this post by Frank Küster
Frank Küster <[hidden email]> writes:

> It would be good if there was a way to find out "problematic" packages,
> by extracting information about

> - how many bugs does a package have
> - how many of them don't have a single response
> - how many have not been dealt with for n months (or days/weeks for RC
>   bugs)
> - how many packages depend on the package

> and try to create some rating or ordering.  One could then not only
> identify packages that could use some work, but also for which of them
> it's most useful.

<http://haydn.debian.org/~thuriaux-guest/qa/global.html>

Was posted to debian-devel a few days ago.  :)

> Another good thing would be an effort to go through important packages'
> ancient bugs and clear them up.  E.g. all those, mostly years-old dpkg
> bugs that report a segfault.  Either something should be done about
> them, or they should be closed.

Amen to this.  As soon as I finish a few other projects related to my own
packages, I'd been thinking about picking one of those packages and
volunteering to do bug triage.  I don't see how anyone can find anything
in the BTS when a package has hundreds of bugs, and certainly I doubt new
bug reporters are really reviewing all of the existing bugs if there are
more than a hundred of them.  (debbugs's strong point is handling a small
number of bugs on *lots* of different packages; I find it somewhat
difficult to follow when dealing with a *lot* of bugs on a single
package.)

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Frank Küster
Russ Allbery <[hidden email]> wrote:

> Frank Küster <[hidden email]> writes:
>
>> It would be good if there was a way to find out "problematic" packages,
>> by extracting information about
>
>> - how many bugs does a package have
>> - how many of them don't have a single response
>> - how many have not been dealt with for n months (or days/weeks for RC
>>   bugs)
>> - how many packages depend on the package
>
>> and try to create some rating or ordering.  One could then not only
>> identify packages that could use some work, but also for which of them
>> it's most useful.
>
> <http://haydn.debian.org/~thuriaux-guest/qa/global.html>
>
> Was posted to debian-devel a few days ago.  :)

That's a nice starter;  the number of depending and build-depending
package would be a nice extension.

Thanks, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Erinn Clark
In reply to this post by Christian Perrier
* Christian Perrier <[hidden email]> [2005:12:22 08:10 +0100]:

> > > Bureaucracy is often designed to do lots of things "better" and it often
> > > doesn't achieve them. It creates needless hassle, more 'paperwork', and
> > > has very few benefits besides making people feel like they've done
> > > something useful when they haven't.
> >
> > You are saying that requiring people to find co-maintainers is
> > "bureaucracy"?  Someone I know well recently got co-maintainers for
> > three of his packages by posting a single message to debian-devel.
>
> I think that what Erinn wants to say is more that *forcing* (or
> putting pressure on) maintainers to find co-maintainers would be
> "bureaucracy".

If something makes people's lives complicated for no gain and makes them
jump through hoops to get the same exact thing done, I consider it
bureaucracy. This rule would qualify under that definition.

> I think that she will however agree that *encouraging* co-maintenance
> for "key" or "important" packages (which is a very vague definition)
> is one of the ways to go. But she will probably be able to say it by
> herself: I'm just interpreting....

Not necessarily. I would encourage team maintenance on either
exceptionally large packages (or groups of small packages) or
packages where the maintainer is unable to handle the amount of work
(bug reports, constant upstream releases, etc.) Conversely, I might also
encourage single-person maintenance on packages with ineffective teams
(see Andrew Suffield's mail about this; he basically covers this
territory.)

The fact that a package is important (note: not referring to Priority
here) is not indicative of the amount of work necessary, nor is it
indicative of the amount of time and expertise a given maintainer has
for it.

--
off the chain like a rebellious guanine nucleotide


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

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Christian Perrier
> The fact that a package is important (note: not referring to Priority
> here) is not indicative of the amount of work necessary, nor is it
> indicative of the amount of time and expertise a given maintainer has
> for it.


Sure. However, an "important" package will more badly suffer from lack
of maintenance during several months or even years.

This is the main weakness of packages maintained by single
individuals. By experience, it takes time before it becomes obvious
that the person who was very well maintaining this or that package is
no more able to do so....or lacks time and is slowly neglecting it.

At the very minimum, a team maintenance will increase our chances to
have a faster reaction in such cases....

I perfectly hear your objection to an increased pressure to use team
maintenance and maybe avoid putting too much "social pressure" for
team maintaining everything. I think this discussion had the advantage
of making the issues clearer and give more clues to people who will
have to make the choice of team-maintaining something.




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

Reply | Threaded
Open this post in threaded view
|

debbugs tangent (was Re: Thoughts on Debian quality, including automated testing)

Erinn Clark
In reply to this post by Russ Allbery-2
* Russ Allbery <[hidden email]> [2005:12:22 09:14 -0800]:
> (debbugs's strong point is handling a small
> number of bugs on *lots* of different packages; I find it somewhat
> difficult to follow when dealing with a *lot* of bugs on a single
> package.)

OT for this thread, but: do you notice this even with usertags/user
categories? I'd be curious to hear suggestions for improvements.

--
off the chain like a rebellious guanine nucleotide


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

Reply | Threaded
Open this post in threaded view
|

Re: debbugs tangent

Russ Allbery-2
Erinn Clark <[hidden email]> writes:
> * Russ Allbery <[hidden email]> [2005:12:22 09:14 -0800]:

>> (debbugs's strong point is handling a small number of bugs on *lots* of
>> different packages; I find it somewhat difficult to follow when dealing
>> with a *lot* of bugs on a single package.)

> OT for this thread, but: do you notice this even with usertags/user
> categories? I'd be curious to hear suggestions for improvements.

I'm not sure yet; I haven't tried hard to use usertags to work around
this.  For the packages I've worked on so far, it's been easier to just
fix the bugs until the bug list got down to something reasonable.  I think
it's likely to help a great deal, though, and may largely take care of the
problem for developers (although it doesn't help the reportbug problem).

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


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

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Raphael Hertzog-3
In reply to this post by Daniel Ruoso
On Thu, 22 Dec 2005, Daniel Ruoso wrote:
> > In the PTS, I'd like to be able to point people to the CVS/SVN/arch
> > repository used by the maintainers, however I can't because the
> > information is not stored, or is stored in a non-formal manner in
> > README.Debian.
>
> Hmmm... You probably pointed out the best way to achieve that... If you
> look carefully, you'll see that the PTS uses informations that are
> spreaded around several subsystems...

I know that, I've written it ! :-)

> So, the nicest way is to create yet another subsystem that would manage
> this type of information, and once many people starts putting
> information there, the PTS will include it also...

Why should I create yet another unofficial thing while we already have
proper infrastructure in place to distribute meta-data about our packages ?

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Kevin Mark-2
In reply to this post by Adrian von Bidder
On Wed, Dec 21, 2005 at 03:07:10PM +0100, Adrian von Bidder wrote:

> On Wednesday 21 December 2005 12.23, Thomas Hood wrote:
>
> > I don't think that it is ridiculous to require that every package have a
> > team behind it---i.e., at least two maintainers.  First, if someone can't
> > find ONE other person willing to be named as a co-maintainer of a given
> > package then I would seriously doubt that that package (or that person)
> > is an asset to Debian.
>
> The problem is: do you honestly want to force people who don't want to have
> comaintainers on their packages to leave Debian?
Hi vbi,
Packages, not being sentient, don't mind being comaintained, its people
who have objections to comaintaining packages. So its a social problem,
not a technical one. In most cases the comaintainers will not be equal
in technical skill, social skills, etc. Working together SHOULD benefit
both people and Debian. Does Debian need less/anti social folks? Is it
beneficial to Debian/the packages/the users? The lesser skilled
person(LSP) could gain skill. The more skilled person(MSP) should be
able to give the LSP some directed task (like I read about in the NM
proposal from 'HE'), thus providing a type of apprenticeship. The other
person does not have to know everything about the package, but could
offload some of the effort of the MSP. This allow the LSP to gain
technical as well as Debian skills(debian workflow and social norms). So
the LSP could be in the NM queue or be a less experience DD or someone
less skill in a certain language/specialized Debian task, this would
provide some way to bring folks in who want to expand their skills/role
but dont want to takeover a package like in certain one-point-of-failure
tasks.

>
> Or do you want people who really don't want to have comaintainers for their
> packages to put somebody in just so they are following the rules, while
> they regard anything done by this comaintainer on his own like they would
> regard an intrusive NMU?

Well if someone would treat another maintainer in that way or would
think an NMU intrusive, is that person being as social as Debian
expects? Is being able to working with someone (even if they may be less
skilled) something uncommon to Debian?

>
> Don't misunderstand me: team maintenance is great, and I think it makes
> sense even for small and trivial packages.  But trying to force anybody to
> do anything is no productive in Debian (and we'd have to modify the
> constitution for this, anyway :-)

I guess there could be expections like there are for other things in
Debian (like p-a-s) but like openness, the more [comaintained] , the better.

pax vobiscum,
Kev
ps. happy $HOLIDAYS and $YEAR++
--
counter.li.org #238656 -- goto counter.li.org and be counted!
      `$'         $'        
       $          $                      _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$$$$$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$     $ $$ggggg$ $     $ $ ,$P""  $ $    $
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $    $
 `Y$$P'$. `Y$$$$P $$$P"' ,$. `Y$$P'$ $.  ,$.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Adrian von Bidder
[lots of snippage]

I fear I don't see your point - and I feel you don't see mine.

Here's why I feel *forced* comaintainership is not a solution:

Maintainers divide in
 (i) those who already work in teams on their packages
 (ii) those who don't.

Ignore (i).

(ii) divides in
 (a) those who do a good job
 (b) those ho don't.
Ignore here what metrics we use to decide that.

This division is not useful because (a) maintainers may become (b)
maintainers over time.  So there's

 (a) those who know when to ask for help and
 (b) those who don't.

Now, my claim is that only this (b) is what the forced comaintainership will
try to solve.  And badly, because I assume that those latter maintainers
are also those who would, probably, object anyway to forced
co-maintainership, and so would either ignore the order, be forced out of
Debian in consequence, or pay lipservice by putting Random Joe Developer
into Uploaders (I'm not claiming they'd do that without consent of Random
Joe, but I claim that he'd never do anything on the package, and
consequently would not make a difference even if the package is relatively
badly maintained.)

The other side, and we've seen some people say this in this thread already,
is that even if a maintainer asks for help, he may not get any - IIRC nis
was one such package, and I claim that its still used by quite a few, so in
theory somebody should be found.

Ok, I hope this is stated clearly enough.

cheers
-- vbi

--
Stilblüten aus Schreiben von Versicherungsnehmern:
Meine Antwort vom 17.7 hat sich offenbar mit Ihrer Erinnerung
gekreuzt.

attachment0 (398 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Stefano Zacchiroli
In reply to this post by Lars Wirzenius-2
I fully support your campaign Lars. I've ever been willing to write
automatic tests for a lot of packages of mine. And even a large subset
of them (all OCaml related ones for example) can benefit of the very
same test applied to them. I never added the test simply because there
is no infrastructure for doing it and I'm thus stick to: build the
package -> dpkg -i it -> manually run the test. Surely an error-prone
practice.  I would really like to have a standardized way to do tests.

Thanks for your study on this!

>     Let's take quality assurance seriously
>     ======================================
<snip>
>     * Reporting serious problems found by lintian/linda as bugs
>       against packages.

Still, I think we should start from simple objectives which can be
easily achieved. The one above qualifies in this set IMO.

I know a lot of lintian warnings/errors about packages of mine are
sitting on lintian.debian.org unaddressed. Had them been reported on the
BTS, I know I would have fixed them. It's stupid, I know, but I've ever
used the BTS to drive my Debian work and I believe a lot of other DDs
are working the same way. Adding a (semi-)automated mechanism for
reporting those warning/errors as bug report would improve packages
quality.

--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Andrew Suffield
In reply to this post by Thijs Kinkhorst
On Thu, Dec 22, 2005 at 10:43:34AM +0100, Thijs Kinkhorst wrote:

> On Thu, 2005-12-22 at 08:38 +0000, Andrew Suffield wrote:
> > On the other hand, I think there might be some benefit to requiring
> > that the Maintainer field must always denote one single Debian
> > developer, who would be the "buck stops here" guy for that
> > package. Not an applicant, not a mailing list, and not a group of
> > people.
>
> This "not an applicant" thing is a bad idea. As you might know, the
> NM-process is designed around the idea that someone has to prove they're
> up to the task they want to do. That's why for packagers it's required
> to have packaging activitity. Disallowing them to have the final
> responsibility over a package disables you to evaluate whether they're
> actually fit for this responsibility.
Actually it doesn't, you could work it out something like this:

The maintainer is a developer who is ultimately responsible for the
package. The applicant does most of the work. One of the primary
criteria for judging the applicant would be how much work the
maintainer has to do - the question put to them would be of the form
"Would you be comfortable with handing this package over to this
person, after watching them work for N weeks?".

The issues with the current system are that we end up with a lot of
packages being non-maintained by failing applicants, and we get a lot
of useless packages added to the archive just because an applicant
needed to find something of their own. This scheme should fix the
former and reduce the latter.

--
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on Debian quality, including automated testing

Mark brown-22
In reply to this post by Adrian von Bidder
On Fri, Dec 23, 2005 at 08:40:22AM +0100, Adrian von Bidder wrote:

> The other side, and we've seen some people say this in this thread already,
> is that even if a maintainer asks for help, he may not get any - IIRC nis
> was one such package, and I claim that its still used by quite a few, so in
> theory somebody should be found.

ish.  There was one person for nis, though others have posted similar
examples where nobody at all stepped forward.

The thing with NIS (and I imagine other things too) seems to be that
while it's quite widely used it mostly does what people want already so
things are very static and there's relatively little need for much work.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

12345