[epiar-devel] Pushing changes to the Epiar mainline

[moses]

I agree with this with this completely.  A lot of work is required in

	1) File cleanup
		Some test folders are found and not needed in a push
		Files can be moved around (i.e. fonts in fonts folder)
			(especially in the main folder)
		Some sub-directories exist in directories that aren't needed after
some examination (i.e. .deps for build dependencies, test folders, etc.)
		Actually had a "Segmentation fault" error moving all the .png files
into an "images" folder though I set the right paths for them.  Working
on that...
	2) Documenting the work (i.e. comments, packages needed, what is
expected from code for future reference)
	3) Code cleanup
		Some of the coding is generic in the sense that there are better ways
of implementing the code.  Some of it being obvious, other parts
requiring some consulting (i.e. floats vs. ints in some cases - how does
this work better?)
	4) A workable compilation with an updated Makefile for libraries and
sub-projects, and documentation for this in BUILDING or README.  You can
referr to my main Makefile.am for an example

To make things more interesting my push currently, though unstable,
requires some other packages in addition to Lua that need ".configure"
and "make" first before making the main Epiar.  Yay!  This is just an
expirement though, as I'm working at examining the best results for a
Graphics type of engine that can handle more than one feature (i.e. more
detailed settings in options.xml for doublebuffering or not).

If you want to check how I'm trying to cleanup up the code and structure
a bit, you can look at my fork (http://github.com/moses7/Epiar.git).
Some of it might have some ideas that may be useful, particularly in the
"Graphics/images.cpp" coding.  Again, this isn't official and only
expiremental as I get use to how the code's architecture is setup.

It looks great between all the versions btw, but I think it should get
cleaned up before we put any of the old features in.

-- Moses

On Thu, 2009-11-05 at 00:26 -0800, Matthew Zweig wrote:
> I've seen and heard a lot of interesting work and ideas being  
> discussed on #Epiar this last week.  But I haven't pulled anything  
> yet, and I wanted to explain why.
> 
> First and foremost, I have no idea if what you've checked into github  
> actually builds.  Nearly all of the discussion recently has been about  
> just setting up and building Epiar.  If you are able to build and run  
> Epiar, send me a pull-request or a patch and I'll get the changes into  
> the mainline.  I have a feeling that we'll get past this hurdle really  
> soon, so there's not much to worry about.
> 
> Second, I really don't want to pull dirty commits, backed out commits,  
> accidental commits or the like.  If you've accidentally pushed files  
> that don't belong in the mainline, git can be really powerful and you  
> can rewrite your entire history.  The .gitignore file I pushed  
> recently has a list of the files that I think should not be checked  
> in.  If you have accidentally checked in any of these files, I'll  
> probably ask you to purge them from the history.  If I've missed some  
> files, feel free to add them to the .gitignore or tell me and I'll add  
> them.  The best way to avoid committing files you don't mean to commit  
> is to use a git gui tool, or use the "git add" staging area.
> 
> Here are two links that I think are useful:
> 	http://help.github.com/removing-sensitive-data/
> 	http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history
> 
> If this is giving you problems, but you still want to push some  
> changes, tell me and I'll do my best to clean up your changes for  
> you.  I'll probably rescind this statement if I get too many requests  
> to do this for people.  Usually, the person that wrote the code is  
> able to cherry pick the important changes far better than any other  
> developer.
> 
> Third, code quality.  If some code looks incomprehensible I may ask  
> for either a rewrite or an explanation.  My threshold for  
> 'unacceptable' should be pretty low, so don't let this stop any  
> participation, but I will try to read through every changeset.
> 
> If anyone thinks that this is unacceptable or somehow tyrannical, I'm  
> sorry.  I don't think these three rules should be too painful for  
> anyone though.  To summarize:
> 	1) It must build.
> 	2) It shouldn't include log files, build files or obviously garbage  
> commits.
> 	3) It should be readable.
> 
> Thanks,
> ~Matt Zweig (knowknowledge)
> 
> _______________________________________________
> epiar-devel mailing list
> epiar-devel at epiar.net
> http://epiar.net/mailman/listinfo/epiar-devel