I should have replied to this some time ago but I guess as the unconference is just a round the corner now is as good a time as any. As an adopter (and a fairly new one at that) if I've understood this correctly it looks like a good thing to us. We'd be moving to a more stable method of including new features and decreasing the risk of complex bugs arising from an orgy of feature committing.
Just to check my understanding, there are a couple of things I'd like to ask. 1. This seems like something of shift in QAing (not that that's a bad thing). Rather than large infrequent community efforts like the 'find fest', there would be feature specific windows during which we get to play devils advocate, looking to see if there are bugs introduced by the feature that the feature committer would need to fix before a commit. Would we need to look at how we encourage this as a community? 2. In terms of timing are we looking at implementing this new system soon? I'd assume that immediately post 1.4 people will have a burning desire to add new features and maybe we should consider if this is the time to try out the new methodology. Unfortunately I can't attend the SD unconference, but I'd really like to see some time put aside to discuss this proposal to see if it could be done sooner rather than later. It might also be an opportunity to quickly hash out the specifics that have come up in the emails responding to Tobias' proposal. Lastly, I think I understand that getting a new feature into trunk will become a slightly longer process, sacrificing speed for stability. However I'd assume that if Trunk were always releasable, the time frame from "successful feature commit" to "availability in official release" would fall substantially. Best Regards Stuart Phillipson | Media Technologies Coordinator Room 1.023 Devonshire House University of Manchester Manchester M13 9PL United Kingdom e-mail: [email protected]<mailto:[email protected]> Phone: 016130 60478 On 19 Dec 2012, at 16:12, James Perrin <[email protected]<mailto:[email protected]>> wrote: Hi All, General comments on features developed in branches: The separation of trunk from feature developed provides many advantages. It will allow those who really want a more esoteric feature that hasn't been merged into a release 'roll their own' with understanding that the code remains unsupported by the project. Do need to have a strategy for resolving conflicts if more than one feature has been agreed to be merged at the same time or do we simply allow one feature in at time and, other features will need to update thier code to work with the new core before they can be merged? On 19/12/12 10:40, Rubén Pérez wrote: - Is the initial commiter responsible if later on we notice that his code breaks something? Absolutely, in my opinion, but it also depends on what one understands by "later on" and if the break comes from a bug in the code submitted or a more complex interaction with the surrounding code. Also, somebody recently pointed out to me that the Agile manifest deprecates anything by the lines of "this area is So-and-So's part" or "I don't do this area of the code; it's John Doe's thing". While I see the difficulty of every developer in Matterhorn knowing *every* part of the code, I also see the advantages or developers being, so to speak "acquainted" with many parts of the code. Strongly agree with this, those developing new features must be responsible for making it work with the core. This includes any necessary changes to the core code. Maybe we need a period of probation after a feature has been added where the original maitainers are resonsible for fixing any related issues. After this period the feature is fully adopted by the project. - What happens with probably small tasks that are not bugs? For example upgrading the Atom Feed to the 1.0 version (what I hope will not be too much to do)? Or adding new unit or integration tests... I'd say upgrades are features and should be addressed accordingly. One of our problems is that developers sometimes focus mostly in new features and completely miss maintaining the existing ones, or keeping them up-to-date. I say "developers" but I'm including myself in the lot, of course. But upgrading things may potentially break some stuff here and there, and I don't see a good idea doing it when we are in the middle of a QA phase (in general). Re. tests, I'd say that they can be added at any time of the process, both in "development time" and QA time. Perhaps in QA one will discover some aspect of a certain part of the code which remains untested and can create a test for it. Tasks where existing functionality is being replaced with a 'better' version of the code or way of doing things should probably be just discussed on list when it's proposed. I don't see a need to vote on it's inclusion when it's ready. It should be developed in it's own branch and go through a proper code review before being merged into trunk. Release strategies: Many users have expressed the desire to have more frequent minor point releases. ie 1.4.1, 1.4.2 etc. This is desirable though for those of us doing very large deployments the opportunity to peform updates are possibly going to be 2 or 3 times a year. To allow end users to better plan their update strategies the timing of these minor releases should be decided ahead of time so fixes have to make the release deadline not the other way around. Spawning maintence branches for these releases would mean that if a critcal issue is found immediately after release, and can be quickly fixed it's can be easily applied to for the 1.4.2 release and made available as 1.4.2.1 We should also consider whether anything other than a trivial fix should be worked on in a branch. As any partially completed fixes in trunk could stall the next release. Regards James -- ------------------------------------------------------------------------ James S. Perrin Media Technologies Team Devonshire House, University Precinct The University of Manchester Oxford Road, Manchester, M13 9PL t: +44 (0) 161 275 6945 e: [email protected]<mailto:[email protected]> w: www.manchester.ac.uk/researchcomputing<http://www.manchester.ac.uk/researchcomputing> ------------------------------------------------------------------------ "The test of intellect is the refusal to belabour the obvious" - Alfred Bester ------------------------------------------------------------------------
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
