Re: [AD] Question about versions

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 25 Aug 2008, at 08:30, Thomas Fjellstrom wrote:
> Can you guarantee you'll stick around and support it? And does it  
> really
> warrant being a full fledged supported platform in allegro? As of  
> late, we've
> been removing fluff, and consolidating the core allegro into a more  
> maintainable
> state, and if recent commit rates have anything to say, it has helped.

Maybe. Personally I think it has to do with people having some time  
and motivating eachother (and things falling into place with the new  
API).

> Already with 4.9 we've seen at least one case of "bad things"  
> happening when
> this policy wasn't followed. Recently with the audio code, KittyCat  
> wrote a
> rather in depth spec, coded a bunch, and sort of just stopped, then  
> someone
> came in to "clean" it up a little and made massive changes  
> overhauling the
> entire audio code base, which has recently been semi-reverted,  
> through a copy
> of the original KC code into a new addon, so this one section alone  
> has caused
> an enormous amount of extra work due to two of the original  
> submitters dumping
> code (yeah, the changes that were made to the original audio addon  
> were
> applied in one large commit, making it hard to separate it all), and
> disappearing.

Here I think the problem is something else entirely: large commits  
being made without prior notification on the mailing list.

Personally I always had the following policy when doing Allegro- 
related commits:
 * If it's a very small change, commit it. Announce it on the  
mailing list with explanation.
 * If it's a large change, submit the patch to AD and wait about 24  
hours before commiting.
 * If it's a really large change, submit the patch to AD and ask for  
comments, wait at least a few days (but likely people will comment on  
it) before submitting.

Now, this is fine for maintenance code (which A5 code at the moment  
isn't), it's a bit slow for production work. Still, I think it's a  
good policy to post and announce *overhauls*, as with the audio code,  
and wait for comments for at least a few days. Sure, it can be  
reverted if it's not suitable, but that takes extra effort.

In this case, the change was announced here first, and it really  
makes little sense to add source to the "Amiga port" in small chunks  
for no good reason other than not accepting "large chunks". I would  
recommend commiting the "bulk" of the port (the src/amiga part) in  
one commit and the necessary changes to the build system (fix.sh) in  
another. Documentation should probably be a third commit.

>  Not only that, code has to follow strict guide lines wrt style and
> license. I'm not suggesting we go down _that_ path, but I do think  
> its about
> time we clear up our own policy regarding this stuff. We already  
> have informal
> "rules", but they are fuzzy at best, and not followed much of the  
> time (except
> for licensing, thats one thing that has to be right all the time, its
> allegro's license, or one thats compatible, or its no go).

I think we have rather clear rules about license and source style/ 
formatting - and I consider the guidelines I posted above to be  
sensible practical guidelines, but they're not formal. Personally I'm  
not sure they have to be (even if they're agreed on, which isn't a  
given) as long as everyone uses their common sense (which is what my  
personal guidelines came from anyway) and we have other people to  
tell them to do so.

Evert