Re: [9fans] devtrace release time

[sqweek <sqweek@gmail.com>]

On Fri, Dec 19, 2008 at 1:54 AM, Steve Simon <steve@quintile.net> wrote:
>> I'm yet to see anyone demonstrate a disadvantage of doing so.
>
> the problems with publishing code is you have to:
>        write the manual
>        document the install process
>        remove all the debug cruft that you where leaving just in case

 No no no, this is all release oriented stuff! Just put the code up so
if someone really interested happens by they can check it out and work
the details out themselves. What's the disadvantage there?

>        field emails about how it:
>                doesn't "Work they way I expected"
>                it suicides if I press Alt-J
>                "the whole design is fucking braindamaged"

 I'm not understanding how feedback qualifies as a disadvantage.
Unless you're writing a twitch game or MMORPG, then I could understand
not wanting to hear from your users.

> and we take prinde in our work, don't we?

 Of course. But it's silly to entertain the notion that code comes off
our fingertips perfect and fully formed. It's software: there's bugs,
there's design flaws, development is incremental. Often it can be
useful long before it is perfected.

> whats worse is if you publish a tar and then somone fixes a load of
> stuff but in the meantime you are working and your code gets out of sync
> so you have to merge by hand.

 At least this represents a modicum of cooperation. Without the
published tar to start from, that someone may well start from scratch
and duplicate whatever effort you've already put in. Good luck a)
finding and b) merging any fixes from a completely separate tree.

> use CVS (or whatever is trendy) I hear you say? Well you have to set that
> up, and if you have CVS you have to police it, what if people check in
> broken code.
>
> It all takes time and concerntration, which would be better spent on
> getting on with the code and sorting it out.

 Disagree. Well, you're right that it takes time. But that time is a
one time cost, to set up and learn to use the VCS. Once you've made
that investment there is no constant drain on your time/concentration.
I'm not sure I agree that the time is better spent coding - I think if
you actually sat down with a modern DVCS like mercurial or git you'd
find it actually creates quite a nice environment for collaboration.
No need to worry about policing anything using the pull model.

 It's not like version control systems have a monopoly on tools you
need to invest time in before gaining productivity from them. Awk,
acid, acme, spin all require a certain amount of time investment to
understand how they work before the become useful tools.

> One of the biggest things we lack is Wifi support (IMHO) and Russ put
> up his incomplete Centrino driver a few years ago. How much interest has that
> sparked?

 Like I was saying, publishing code doesn't *generate* interest. It
just leaves open the possibility of someone using it later.

> Similarly the sshv2 code, though we now have openssh so its less of
> a problem.

 Michiel was looking at this just the other week.

> (my OS has 64 bits and yours doesn't),

 What OS doesn't have 64 bits these days, aside from Plan 9?
-sqweek