Re: [AD] Question about versions

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Monday 25 August 2008, Evert Glebbeek wrote:
> 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).

There is a reason I've been quite insistent. Before I started getting in 
everyone's faces, things were stalled. Even bug fixes were rare. After everyone 
agreed to the dev meetings, that while didn't completely live up to my 
expectations, did manage to get the ball rolling again :)

Probably a chicken and the egg problem, if no one shows interest, or does 
anything, no one shows interest or does anything.

> > 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.

My point would be, given he did come along earlier and has commit access, it 
would have been ideal if he just did the work on allegro svn itself. More out 
in the open. Then I'd have so little to complain about I wouldn't have 
complained at all. I do believe thats why he has the svn account? to work with 
the rest of us (well, mostly everyone else, I still have to finish my boring 
fshook work, and this X multimon support I just started due to trentg getting 
windows support in)

I don't really have a problem with including the port, but given discussions 
we had about slimming allegro down, and removing stuff with few users, this 
sort of goes against it all. Though I guess its fine for Allegro 4, its stuck 
with several other platforms that are rarely used, at least this one will 
hopefully be maintained for a while.

> >  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.

It doesn't happen too often. Maybe I should complain more? ;) I see patches 
come in with the ALLEGRO ASCII art mangled, white space changes, and other 
usually editor caused errors totally missed. If I had the concentration most 
days I'd try and audit every commit that goes by, but many lately have been 
rather large due to 4.9 flux, which makes it harder.

> Evert
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx