Synfig 0.61.10 release. Help needed

Hi dear Synfig’s users and developers!! ( :question: ) :wink:

I plan to release Synfig 0.61.10 at the end of September this year. To do that we need the effort from all the community. :mrgreen:

So I need help for:

  1. Download and build install the latest git master code. I’ll post here a link to the source code and the build instructions based on the git repo as soon as I apply the ‘canvasview’ and the ‘reverse manipulation scale ducks’ to master branch.
  2. The same as above but for Windows. Dear Pixelgeek: we need your help on compile the source code and generate binaries for Windows. Any other windows user help will be welcome.
  3. If there is someone working on build Synfig in other OS (Mac, Solaris, etc.) this is the moment to double efforts and raise your voice!!!.
  4. Test the current bugs listed in the bug tracker. Report any new bug you find and/or deprecate non existing bigs. To find bugs you need to work with the program not only start the application and go. Use it for real work. I know that it is a bit risky due to unexpected crashes. Just try to set the autosave frequency to something small and reasonable.
  5. Complete the synfig-core and synfig-studio translation. We need a complete system. Good translations make it better. Patches are welcome
  6. Update synfig.org. There are several missing pages. Also update the screens with the latest version should be mandatory. To find what’s missing it is very easy. Just start with the Documentation page and explore it trying to find missing links. Anyway there are some of new features that doesn’t have any link even: i.e. Curve Warp layer.
  7. Participate on the Splash Screen Challenge! It will be during September. Apart of improve your skills, your name will be in the Synfig credits!. Help on manage the contest is welcome.
  8. New icons are welcome! There are some icons that comes from the standard buttons icons. Spread your imagination and submit new icons for them!. For example: Seek next/previous keyframe, use low/hi resolution, increase/decrease resolution.

Meanwhile I’ll try to do the following:

  • Solve as many bugs as I can.
  • Implement some new small features. Suggestion are welcome! (and the coders ( :question: ) keep their right to reject or accept the suggestions :laughing: ).
  • Update the wiki on the areas related to source code and build instructions.
  • Post a release candidate #1 as soon as I freeze the code. That needs more testing too.
  • If bugs are found and release candidate #1 needs review then release candidate #2.
  • Perform the task of the previous list within my time, encouragement and skills possibilities.

There are a thing that I need a lot of help. The patch from akagogo’s (SVG importer) would be nice to include in this version. But it doesn’t want to work properly. I’ll try to fix it but I suspect that it is a big effort to someone that doesn’t have any idea on SVG format. I suspect that it can be fixed if it is rebased to master with the fix of the Fedora problem.
If some of you can help on that it will be awesome!.

Thank you!
-G

Great Genete!

I’ll try to help as much as I can which will probably be with more active bug-reporting/testing and working with the wiki.

I’ll see if I can sketch out some new icons as well, as you say they are needed. Some of the icons are quite confusing when they are just standard ones.

I also think we need to create promotional material for this release, a nice press-release and such.

And a small suggestion for a new feature; add buttons for zooming in/out on the timeline in the timeline-panel. (I’ll file a proper feature-req. on this)

Great news! Keep up hard work! Count on me with linux packaging and stability tests. ^___^

I can do the windows builds (assuming no submittals break them) :slight_smile:

Great! I have been waiting for so long :smiley:

Cool a new release planned!!! :smiley:

I won’t have much time these days, but I will can help pixelgeek to track bugs on his windows builds (as I don’t know how to make a build on windows for now :stuck_out_tongue: )

I’d like to ask something:
why will this next release be called 0.61.10, and not 0.62 ?
Is there a rule you follow to name the releases?

There is not rule.
I wrote in the source code page that only when significative changes are in the new release or a new sif (backward incompatible) format comes around it deserves a major number increase.
New version number is not defined yet.
But the good new is that we move!!!

-G

I think drag and drop keyframes deserves a significant number increase.

Chris

I vote for that!
-G

I also vote for 0.62.

A small change like 0.61.09 to 0.61.10 implies a very small fix release, a few bug fixes and thats it. From what I’ve heard of this release it’s a little bit more than that.

0.62 Yay! :smiley:

Apart of what I said on first post (what would make the new release a good release) I need help on create the release tarballs.
According to the Release instructions, it is needed a clean dist copy of the source code (without the .git folder) and then run the make distcheck command.

I’ve replaced the:

svn export https://synfig.svn.sourceforge.net/svnroot/synfig/ETL/trunk/ etl

by:

git checkout-index --prefix=/path/to/git-export-dir/ -a

to obtain a clean index copy.

When I run the autoreconf, configure and make distcheck commands I see some errors because it is was waiting svn etc.

Does anybody have autoconf knowledge to help me on this task?

The configure.ac and Makefile.am should be polished and adapted to the new repository structure.
-G

Are we also going to drop the ‘trunk’ part in the path? That is a svn relic that no longer is needed or desired…

G.

Yes we must. I think that only the autorevision.sh script made by Zelgadis will need some changes. The rest is self contained.

For this release I think we should persist with the three tarballs (etl, synfig and synfigstudio) but we should consider distribute a single package with all the sources and a configure and makefile at root of them.

Maybe you can take care on that? :unamused: (at last fix the current configure and makefiles to remove any svn command and replace by the corresponding (if needed) git command)

-G

Please feel free to kill the superfluous trunk folder. Windows scripts don’t need it.

We do have a few references to SVN in the build process, but they don’t seem to get in the way of anything…

Chris

Regarding to this, the .gitignore file is making me suffer a bit. It has some custom ignores that makes me difficult the tracking of the modified files. Also I think that .gitignore should only ignore (or just never ignore) the files that doesn’t belong to the tracker and are produced during building time. Any other file that the user want git to ignore should be added to that file or by using a custom git exclude file.

See this to know hot to add custom exclude files. kernel.org/pub/software/scm/ … gnore.html

So If you don’t mind, I’ll remove the custom ignore entries in .gitignore to match the proper meaning of that file.

-G

I don’t understand. Can you give an example?

G.

For example the current .gitignore file has the following entries:

[code]# ------------------------------------------------------------------------

ignore the symlinks I put in place to skip ‘trunk’

------------------------------------------------------------------------

ETL/ETL
synfig-core/src
synfig-studio/src[/code]

You have to forgive me because those lines were not added by you but by dooglus. :blush: :blush: :blush:

So I’ll take ride of them to make the .gitignore more logical.

My excuses :slight_smile:
-G

Looks like sourceforge.net will soon support multiple git repositories (the updates for git happen today):

sourceforge.net/apps/wordpress/s … y-support/

Now would be the appropriate time for synfig get rid of the trunk dirs properly and to do a real conversion from multiple SVN projects bundled into one SVN repo into to multiple git repositories with one per project. I’m willing to do the conversion from SVN and the import of the git history from your current git repositories. Is there any interest at all in doing a proper conversion from SVN to git? The current conversion sucks in a variety of ways and I believe will discourage experienced developers from joining the project. If you prefer to work as-is, at the very least you should remove the SVN metadata from changelog entries, fix the authorship information (Name instead of just SVN login names) and move the website synfigskin git repository to sourceforge.net.