Re: [Gnash-dev] Improvements ahead and forking

[strk]

On Tue, May 25, 2010 at 04:00:27AM -0400, Robinson Tryon wrote:
> On Tue, May 25, 2010 at 2:23 AM, strk <address@hidden> wrote:
> >
> > Now I'd like to commit it but dunno where.
> >
> > Committing to trunk (assuming I still have commit access)
> > would not get appropriate review by Benjamin who knows what
> > he's doing more than anyone else at this moment.
> > Also, I'd incurr the risk of my improvements being thrown away
> > by someone not willing to communicate about changes.
> 
> I don't profess much knowledge of the Gnash development process, but
> is it kosher to post patches to the dev list?

Sure, that's the usual path for non-committers.

> If patches can be sent to the dev list, then anyone can post 'em, and
> anyone can review/comment on 'em. If the maintainer(s) of Gnash think
> they're up to snuff, then they'll get merged.

But the problem is that the maintainer of Gnash thinks his own
patches are up to snuff, while to top-two committers [1] of the team
think they aren't.

[1] http://www.ohloh.net/p/gnash/contributors

> I don't use bazaar much at all, but I assume that one can merge code
> from different remotes, like in Git. So what about giving each
> developer their own repo and then aggressively merging code, just as
> long as it doesn't break anything?

Again, the problem is who will be merging code, deciding what to merge
and what not. Current Gnash maintainer seems to be not willing (or
not able) to judge what breaks and what not.

> That way, even if some changes don't initially get merged-in, they
> wouldn't be completely lost. They'd still be there, ready to be
> re-worked and re-submitted for inclusion.

Surely working on a different branch would help not loosing changes,
would just be harder to finally merge it to trunk for a new release
of the "Official" Gnash.

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html