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

Bug#478167: ITP: cowpoke -- Builds a single Debian source package with a remote cowbuilder



On Mon, Apr 28, 2008 at 08:50:38AM +0200, Mike Hommey wrote:
> On Mon, Apr 28, 2008 at 03:02:27AM +0930, Ron wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ron <ron@debian.org>
> > 
> >   Package name    : cowpoke
> >   URL             : git://git.debian.org/git/users/ron/cowpoke.git
> 
> Do we really need a new package for a single script ?

Well, that really all depends on whether other people are interested in
having this available to hack on and use _today_.  I needed it, or
something like it now, nothing else like it seemed to already exist
that I could install and use, and packaged it for my own use, for my
own convenience.  I didn't have to share it, but I did, and given that
it got useful feedback, expressions of gratitude, and even patches to
improve it, faster than it could even get accepted into the NEW queue,
I'd say that I probably made the right decision at this stage -- to
just make it available in the quickest and most user friendly way that
I know.

I could split it into several scripts if that would make the package
more justifiable -- but I'm assuming that the letter of your question
here doesn't quite capture the spirit of what you are really asking.

I didn't have an existing package I maintain that it would have made
sense to slip it into -- and didn't really have the time to try and
engage people (who may not care at all about it) to adopt it when I
was already 'stealing' company time to write it, package it, and give
it away.  By the time I'd done the work that _we_ needed, actually
uploading it was really just a matter of letting it complete its test
suite on itself.

If it helped just one other person today, that tiny little bit of extra
work payed off in delightfully disproportionate ways, and I feel good.
I'm not sure the benefit of debating where it should go for a couple
of weeks first would have rated so well.

> Can't that go in in with cowbuilder ?

Maybe.  I'd have no objection to that, but we'll have to talk to the
cowbuilder maintainer.  In the meantime, a little peer review can only
help everyone make up their minds about where and if this belongs.
I'd expect this will go through a few more revisions before a broader
spectrum of people are happy it does all they need -- it won't hurt to
not tie cowbuilder to a cycle of rapid updates and possible RC bugs
while this initially shakes out.  Even if it looks like something that
cowbuilder might adopt today, I cannot guarantee it still will after
other people start pulling and poking at it in other useful directions.

In any event it will at least want its own binary package separate
from cowbuilder -- since it's intended to run on machines that don't
have cowbuilder installed, and with cowbuilder machines that don't
normally have people actively hacking on them (and hence need this
installed) -- most machines only want one or the other.

If it stabilises and the cowbuilder maintainer is happy to include
it in that source package, that would be great.  But it would have
been a little silly of me to preemptively fork cowbuilder to develop
this.  I am conscious of package bloat though, and if this package
can be gotten rid of, either by merging with something appropriate,
or me filing a removal request if it proves to simply suck and be
useless, then I'll wave goodbye to it with the same sense of doing
continued good that I uploaded it with.

Sorry for the rant, but I do think about these things too ...
and I figure if you've felt the need to ask, you probably want
better answers than:  1) Yes. 2) I don't know yet.

Cheers,
Ron





Reply to: