[epiar-devel] Pushing changes to the Epiar mainline

Thu Nov 5 08:23:14 PST 2009

Another thing that needs mentioning is a stressing of communication.  
You have to tell people in some detail what it is you're working on  
and why you're working on it. If you don't, when the time comes to  
push changes into the main tree, you may find people rejecting them  
outright even if the code is good.

It's a bit difficult, especially early on in a project, where people  
don't know the ethos of the project, and, especially with our reboot  
of the code tree, don't know really what to expect at all. That's why  
you need to communicate with us on epiar-devel what you hope to do to  
know if we even want it.

Of course as an open source project, we'll take anything, but in being  
a game, there's a certain level of design and a narrow range of  
acceptability when it comes to features, visual quality, etc.

For example, Matt recently wrote a really good bit of code bringing  
Lua scripting to Epiar. I knew about this ahead of time but what if we  
were already looking into tcl scripting and Matt just dumped all his  
Lua patches on us: we'd have to reject it possibly and waste a lot of  
Matt's time.

- Chris

On Nov 5, 2009, at 12:11 AM, moses wrote:

> I already checked into this, and it goes like this:
>
> 	.git default is automatically created, about 2 megs
> 	All .png files and KDevelop projects are about 2 megs in main folder
> 	A duplicate images folder with pngs, about 1.5 megs exists in images
> (as explained before)
> 	A number of projects that I am using were added on, SDL_draw,  
> SDL_gfx,
> SDL_ttf those are about an additiona 3 megs or so
> 	Some test folders that I am examining still exist from old pushes,  
> i.e.
> Debug which are somehow still part of the build
> 	Sub-projects like SDL_gfx, SDL_draw and SDL_ttf additional contain  
> some
> of their own KDevelop workspaces which accomodate about 1 meg each.
> 	You can check my .gitignore, but I hate being technical as git-rm
> deletes the files hard too...  Haven't figured out how to remove them
> from repository only.
> 	Fonts about 1/2 meg...
>
> 	That's the reason for the size, most accomodated to the .git  
> folder.  I
> tried removing that, but I think git-clone creates this  
> automatically...
> 	The rest are some cleanups from those other packages I haven't  
> checked
> out yet...
>
> 	Tis only 10-20 megs :)
>
> On Thu, 2009-11-05 at 02:58 -0800, Matthew Zweig wrote:
>> Moses,
>>
>> I'm glad you agree, but currently, your repository is the one I'm  
>> most
>> worried about.
>>
>> A brief scan of your repository shows that of the 24 in two days,  
>> most
>> of them have the commit message 'Testing' with no other information  
>> on
>> what changes were made.  Making lots of commits is great; I  
>> thoroughly
>> support committing experiments and tests.  But not without some
>> information on what you're testing, what the experiment is, etc.
>>
>> Also, you pushed binary files and long long files accidentally.
>> You've removed them from later reversions, but git is a revision
>> control system, it doesn't forget about the files unless you
>> explicitly tell it to.  This means that downloading your repository
>> is  about 9 megs, whereas downloading mine is about 3 megs.  Git does
>> a great job of collapsing text files and an okay job of collapsing
>> binary files.  SVN doesn't.
>>
>> As excited as I am to get your changes, I would really like you to
>> clean up your repository before I pull anything.
>>
>> The two sites I linked to explain how to (1) remove dead or unwanted
>> files, and (2) modify change history.  You can either rewrite the
>> commit messages, or collapse multiple changesets into one.
>>
>> Thanks for the good work,
>> ~Matt
>>
>> On Nov 4, 2009, at 10:26 PM, moses wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> epiar-devel mailing list
>>> epiar-devel at epiar.net
>>> http://epiar.net/mailman/listinfo/epiar-devel
>>
>> _______________________________________________
>> epiar-devel mailing list
>> epiar-devel at epiar.net
>> http://epiar.net/mailman/listinfo/epiar-devel
>
> _______________________________________________
> epiar-devel mailing list
> epiar-devel at epiar.net
> http://epiar.net/mailman/listinfo/epiar-devel