[sraue]

Hi Devs,

i want ask and share some ideas about using branches in the development process of xbmc. It seems trunk is used for integrating new functions that are not ready or dont work. Why you not using branches for this?

For example:
There are a branch for development of the addon functions. All addons related development was done in this branch up to the time of merging this branch to trunk. Afterwards we had a new and great feature to enable/ disable scrapers and visualizations that has worked. Since some days this feature are completly broken because of some changes for another new features related to the addon browser. Why dont use the addon branch again if creating further functions (merging trunk to this branch, developing new features, merging back to trunk if its done)?

Bug reports will be answered with "even debt if you work with trunk", you made it not easy to find issues, fixing bugs, and developing other projects around xbmc.
There are some other projects, with many developers, that work approximately around XBMC. There are developers that creating themes, writing plugins and scripts and there are distributors that would integrate XBMC in any distribution. These developers are working also with trunk to can release there own features, distributions, themes, plugins, scripts in the time if an new xbmc will be released. They cant start development after releasing an stable XBMC!

I would prefer to creating new functions in its own branches, and if they are done you can merge this function to trunk. Developers of other projects will help you to find and fix issues, this fixes can be integrated in trunk directly. So its also easyer to keep release cycles ore use smaller release cycles. If an new function are not ready so it evenly will evenly be released in an later version.

[erhnam]

They already use branches for experimental stuff:

http://trac.xbmc.org/browser/branches

[sraue]

They already use branches for experimental stuff:

http://trac.xbmc.org/browser/branches

i know about this, but they also uses trunk for implementing new features that breaking xbmc and are not ready for use. what i mean are using branches for development new features and using trunk for finding and fixing issues (after merging an branch).

[spiff]

because at some point, branches lead to code rotting. for instance, the addon unification which had been sorta developed off trunk for two years. the only way to get attention of the full dev team is to force the issue. we announced the merge, we told people to stay away from trunk for the time being and stated the last safe revision. the svn is a tool for our development. it's there for us. third parties will have to live with breakage now and then.

that being said, the addon merge has turned into more of a disaster than we first thought it would. part of the reason is lack of devs picking up on the tasks to be done. be patient, we're working as fast as we can. but after 10-12h work days it's hard to find the energy to keep coding in your spare time at the end of that day.

last thing we need right now is a whine fest.

[topfs2]

Big thing here is that, perhaps unlike other projects, we don't consider trunk stable. Our workflow consist of a feature freeze and bugfix and we then branch from trunk when we consider it stable.

The thing is, as spiff points out, is that this works internally for us. Also since all developers have the most recent part of code and don't have to merge X branches to have the features enough to code. Also there are very very few developers that have all possible platforms its usable to have all developers ontop of all the development code.

[sraue]

but after 10-12h work days it's hard to find the energy to keep coding in your spare time at the end of that day.
...
the svn is a tool for our development. it's there for us. third parties will have to live with breakage now and then.

I think not so. It is also a tool for the community. I think the XBMC developers are interested in a stable and great release. In addition it is necessarily to be found issues and bugs during the entire development phase and repair these time near to exclude any sequence errors.

I think, for example the theme, plugins and scripts developers - they have also just little time and for this it is also difficult to find time after work to work on their projects. But this developers will also present a release of their projects with an new release of XBMC. The existence of many other third party projects around XBMC is that what make XBMC better and greater as other Mediacenters.

For example i do not know how Alwinus think, but I think he can perform at the moment no actual merging. This would break the entire functionality of the pvr-testing2 branch. He should now wait as long to perform a merge. I think also, you know that it often need much time to solve merge conflicts after an long period of not merging. Time, that can spend to work on other things or new functions.

last thing we need right now is a whine fest.

this is not the point - i am the latest that do an "whine fest". what i would say is to make the development easyer for all (and say not things like "even debt if you work with trunk" or others if we help finding and reporting issues that exists for some days) - XBMC devs and third party devs. Then it becomes better for all - also for the "end-users"

[davilla]

Some merges are easy, some are hard and sometimes un-foreseen issues arise after the merge. That's just life in svn trunk.

When we anticipate issues, we disable nighties (as we have done). Addons is a big merge that touches just about every aspect of XBMC and some bits require "all hands" involvement. The decision was made to merge it into trunk to get "all hands" involvement. Bad or good that's the way it is.