Re: [AD] Question about versions

[Thomas F. <tfj...@sh...>]

On Sunday 24 August 2008, Colin Ward wrote:
> On 24/08/2008, you wrote:
>
>
> [snip]
>
> >> I didn't really think of that, as I have a bunch of beta tests and
> >> another person who is busy porting every game he can get his hands on
> >>  to the Amiga. So in terms of people to do "QA" it's all covered.  I
> >> could put it in Subversion but I doubt there are any other Amiga users
> >> (especially Amiga OS4 users) on this list...
> >
> > The Actual developers of upstream Opensource projects tend to like
> > regular updates. How would you like it if you were part of a very small
> > team and allong one day comes a guy who you've heard from twice, who
> > dumps tens or hundreds of kb of code? What are you going to do with
> > that code? Do you have the time to check each and every last line for
> > possible issues? Not likely.
> >
> > And I don't think we should accept a large dump either.
>
> Please Thomas, I'm not a noob and I have been involved in many open source
> projects over the years.  I understand what you mean and of course I
> understand the importance of incremental commits and being involved in the
> development of the project as a whole (that's why I'm on this list).  But
> in this case the code that will be committed will live in src/amiga and is
> completely independent of the rest of Allegro.  In other words, it will not
> break or modify generic Allegro code in any way and the only people who are
> affected by its addition to Subversion are Amiga users (all three of 'em!).
>
> So if I do finish the port locally and then commit a completely working and
> tested version to src/amiga then I don't see why that would be a problem.
> After all, for a new port you are going to have to accept a "large dump" no
> matter what stage of porting that code is up to because it is a whole new
> platform.

The major problem is the code dump, and the extra work it entails for those of 
us that like to audit commits, as well as make sure allegro in its entirety is 
maintained for the foreseeable future.

Allegro has had a history of large sections of it languishing for YEARS, some 
of it due to people dumping large changes into allegro, and disappearing.

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.

I've been saying this for a while, and heck, I may be completely overruled, 
but any moderately to large sized chunk committed needs to have a committed 
(hah!) maintainer, and if we catch a hint it is just a code dump, it should 
_not_ be integrated, no matter how useful the code. (note, the maintainer 
doesn't have to the the original submitter, just someone willing to do the 
work to keep everything up to date)

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.

Maybe the great ass himself (linus!) is rubbing off on me, but it does make 
sense. Subversion has the same sort of policy, but they take it a major step 
further, they WILL NOT take large dumps. At all. Even if its something they 
want. 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).

Anyhow thats enough rambling from me for now...

p.s. I'm not trying to pick on you (Colin), but I do think this stuff needs to 
be sorted out.

-- 
Thomas Fjellstrom
tfj...@sh...