Re: [Gnash-dev] Dictatorship again ?

[strk]

On Thu, Dec 09, 2010 at 09:22:14AM -0700, Rob Savoye wrote:

>   The change was made because the behavior was broken. Besides, you
> reverted my fix yesterday.

That's the reason why I made the initial change.
Since you can see exactly who committed it (me) if my change broke
something you should ask _me_ to fix it, giving as many details about
what's broken as you can.

This is also because it is unfair for you to spend hours on something
introduced by others.
That's what we'd all do if others break something.
And that's what we did put black on white on the wiki.

>   Yes, you probably shouldn't work on configure/build code, as you
> obviously don't understand how it all has to work.

The only think I don't fully understand is the packaging part.
I know how configure/build works.

My revno.h generation model was well thought and designed
One example: 'make revno.h' gave you exact feedback about what
was going on, with 5 possible outcomes:

1. Current revno.h is up to date ($${nick} $${revno} $${comm_id})
2. Updating revno.h ($${nick} $${revno} $${comm_id})
3. Generating revno.h ($${nick} $${revno} $${comm_id})
4. Source is not in a git repository, revno.h won't be updated
5. You don't have git installed, revno.h won't be updated

See how the code you keep committing deal with these situations.

>   Strk, you reverted my change first... I didn't revert your change, I
> fixed the Makefile code instead.

Wasn't a technical git revert, but had same effects.

>   I'm seriously pissed off. I've lost 2 days cause of your changes. You
> broke *all* package building, I had no choice but to fix it so I could
> build package snapshots.

File a bug instead, as the commit policy dictates.
Is it critical to have snapshot packages built every hour ?

> The big issue, which
> you keep refusing to acknowledge is before it had a default if git
> wasn't installed to the current date. You keep removing that, and I
> depend on that working...

Let's talk about that for a moment ?
What does it pay defaulting to a date when normal operations have a
sequencial version ?

Which package is newer: gnash-1245 or gnash-20101234 ?

I think is not a good idea to mix.
We need be consistent in package version naming.

If revno.h is not there AND ( you don't have git or sources are not in
a git repository ) THEN there was a bug in the package you got your sources
in. That has to be fixed.

>   If you could just get off your high-horse and realize we all cause
> occasional problems, we'd be able to cooperate much better. Instead you
> seem to have this righteous anger at nothing... You'd prefer to yell at
> me instead of talk.

I never start Rob.
You wake up, get on IRC and start complaining about what an awful commit
I made and how you'll be spending days to fix what I broke.
Try to make good bug reports instead, and things get worked upon.
I'm still here, working on gnash. Even w/out a budget.

>   So let me get this straight. You broke package building on all
> platforms, and I fixed it. What is the problem ? I though that was
> called working together.

The technical problems are being reported cleanly above and in
other mails. Social one is just about respecting the policies we
gave ourselves: respect the work of others.

After some attempts some of them have been worked around (while they
were perfectly working before).
What's still happening with current version (17b5ba8):

 - revno.h has inconsistent versioning depending on presence or absence
   of the file in distributed packages
 - revno.h generation doesn't give much feedback. Gives a warning/error
   on first run (.lastmod: No such file or directory) and says nothing 
   when not updating (so you don't know the reason).
 - tarball contains a correct revno.h but when you ./configure && make
   after extracting the tarball you get revno.h re-generated using the
   date default: Generating revno.h (master 20101210 none) 

I'm kind of tired to go look for others, since I've spent hours on these
in the first place.

I'd ask you to get back to my first commit (the one you destroyed)
and try again to figure out what was really wrong with your packages.
Mine was e7606177a6c4c5e7a7ab4c085a7328671ca9ff24 (for reference).

But yeah, why keep spending time ?
Feel free going on to fix all of those, but _stop_ saying I broke
things as you are still fixing what _you_ are doing wrong.

--strk;

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