Re: ITP (really ITrP): bigbrother
On Mon, Jul 31, 2000 at 02:55:30PM -0700, Seth Cohn wrote:
> J Currey wrote:
>
> >The older versions had a more liberal license. I stopped using big
> > brother as their license became appropriate of "big brother" ;).
>
> Incorrect. The license was nearly identical. Go check out the package
> if you wish, it contains the old license.
>
Yes the 1.09c license is nearly identical. I dumped BB before that.
>From README.CHANGES
Additions for 1.06:
Copyright clearly asserted just about everywhere. New
and clearer license agreement.
I don't know what version I was at. This was long enough ago that details
are exceeding vague in my mind. There was a forked project
at the time, using the original license. Please don't make me dig
though history to show this, it's of no value now.
>
> Huh? It's in non-free already. the ITP should fix the problems with a new
> version. Why would you want to remove it?
>
> From Potato, I understand. Even if I put a new package up today, it's too
> late to change the potato version, which is obsolete by a few versions.
Yes, it's too late for potato.
I was hoping you'd go the route you possibly indicted,
to software with liberty or whatever you wish to call it.
<Choir Preach>
Code that cannot be freely modified (and distributed) is no better
than closed source (unless you don't honor licenses).
</CP>
I would get explicit permission to make modifications (required
for packaging), since rights not given are reserved.
The only place it could be removed from was woody.
Well, you sound determined, and committed.
As if it this will influence you...
What is it that so impresses you about big brother?
"The amazing support" -
I'll send a jock strap, bra, whatever you want :) .
Please assume my knowledge is of a earlier version.
It's monitoring capablities are in mon, mrtg,rrd,...
It reporting capablities are in gnats, or debian bug tracking
If you had the "canned" glue for this to install easily
(not that bb installed easily, mind you)
>
> > There aren't any release critical bugs against it, but maybe there should
> > > be (??). Someone might want to take a long look at other similar packages
> > > with _long_ standing bugs against them... is it in Debian's best interest
> > > to ship with long standing but non-critical bugs that have been fixed in
> > > an upstream version but not updated in Debian (for many reasons)
> >
> >Please do file appropriate bug reports against them, not "release critical".
>
> Sorry, my mistatement. What I meant was:
>
> 1) bigbrother seems to have at least one bug report that says it's broken
> on install. This seems ripe for a release critical bug. Stephane is away,
> and it's still technically his package, or else I'd file it myself.
My take on Release critical is it refers to the Debian release, not just the
individual package.
<PASTE developers-reference.txt.gz>
3.5. Managing Release Critical Bugs
-----------------------------------
Release Critical Bugs (RCB) are the bugs of severity ?critical?,
?grave? and ?important?. Those bugs can delay the Debian release
and/or can justify the removal of a package at freeze time.
</PASTE>
The severity levels are:
<PASTE http://www.debian.org/Bugs/Developer#severities>
critical
makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package.
grave
makes the package in question unuseable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package.
important
any other bug which makes the package unsuitable for release.
normal
the default value, for normal bugs.
wishlist
for any feature request, and also for any bugs that are very difficult to fix due to major design considerations.
fixed
for bugs that are fixed but should not yet be closed. Bugs fixed by non-maintainer-uploads have their severity set to fixed.
</PASTE>
At worst it would make the package unsuitable for release (important).
Some packages are not functional after installation
and require configuration beyond the scope of the installation scripts.
I would put the bug as normal in preference to having the package
removed during freeze.
Anyone who cares enough can file a bug report, the maintainer mostly
determines the response to it.
>
> 2) Other packages with very outdated versions, where the upstream has
> fixed the problems, and the maintainer hasn't kept up, should be relooked
> at. Maybe a nearly orphaned status is needed? (i.e. Maintainer has a
> working version, and isn't interested in updating it?)
>
> Warren wrote:
> >There is a GPL'd replacement called Big Sister.
> >http://bigsister.graeff.com/
> >
> >I have never used it so I can't comment on its functionality, but it
> >would solve the licensing issue.
>
> Big Sister is BB cloned but using perl instead of shell scripts. It's
> good, but the feedback I've gotten from users of both is that BB is still
> better at this point.
>
> Yes, it would be good to package it also. Giving people a choice would be
> best,
> wouldn't it? That way, either or both can be used.
>
> In fact, I may ITP big sister too, just to make sure they can be
> replacements for each other as packages.
>
> Seth
>
>
>
>
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
--
It has also reluctantly come to the conclusion, for the same reasons, that a
structural remedy has become imperative: Microsoft as it is presently
organized and led is unwilling to accept the notion that it broke the law
or accede to an order amending its conduct.
Reply to: