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]
w: 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]
_______________________________________________
