Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")

[Aaron Bentley]

Tom Lord wrote:

> Those both require project-specific rules to be followed.  `submit'
> especially just cries out for something turing complete.   Other
> examples are not hard to construct.

Rules written in a turing-complete language can be resistant to 
automated analysis and modification.  To find out what they do, one has 
to do them.

I mention this because I'm contemplating automating inventory 
configuration in pyaba, and the notion of modifying the regexes is 
rather daunting.  I can only imagine how much more difficult it would be 
if instead of regexes, =tagging-method was written in a Real Programming 
Language.

> isn't that part of the beauty of a non-corporate (or
> enlightened-corporate) project?  That the maintainer can thrash the
> short-term schedule in a way that maximizes efficiency of production
> rather than trashing the quality of the project in order to hit some
> arbitrary and fairly meaningless deadlines, and thus help to
> _protect_the_quality_ of the project?

Perhaps that is an advantage, but I don't believe you've done that, 
because your merge rate affects the development rates of other 
developers.  My work on tla has slowed quite considerably.  It's also 
has a negative effect on my morale.

I don't want to get too far ahead of you, because that would mean that 
my later changes would depend on earlier, unapproved changes, which you 
might yet veto.  And I don't want to spend the energy developing patches 
if they'll never get merged.

> I know we all have our favorite pending issues but, the truth is, the
> last releases are quite fine, warts and all.

I do find it strange that the latest official releases still have a 
security hole, despite James patching it back in April.  I think it's a 
shame that official releases of tla will commit .id files that don't 
correspond to any source file.

I think there's a difference between bugfixes and features (though my 
boss sometimes forgets).  Off the top of my head, there are three things 
to do with a bugfix:
1. accept it
2. reject it
3. request changes

All three actions provide useful feedback to those working on Arch, and 
there's no great benefit to delaying them while contemplating future 
directions.

> The next steps include
> some big ones.   I've been feeling a need to think through some of
> where we are going before making the problem more complicated by
> merging lots of new stuff in.

Features are something else entirely, and I think you're well justified 
in taking your time with them.  Unlike bugfixes, new features can 
involve structural changes, and it's important not to compromise the 
structure of the system or hamstring future development when adding them.

The story you quoted actually reminds me of another quote:

"Get a shot off FAST. This upsets him long enough to let you make your 
second shot perfect." -- Robert A. Heinlein

In the story, Kim shoots first, without even using a gun.  Keeping the 
initiative means Kim keeps control of the situation, even with a first 
shot that's *far* from perfect.

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.