Workflow Idea for 4.10

[Aaron J. Seigo]

On Friday, March 9, 2012 00:27:51 Alex Fiestas wrote:
> - Keep the 6 month release period

release periods and development periods are not the same thing. the release 
period is, imho, uninteresting in these kinds of dicussions. we're discussing 
development process, which is only marginally related to release processes. 
regardless of the development process, the release process must continue and 
be aided.

> - Keep the current  schedule (soft freeze, hard freeze...)

this, however, is very relevant. :) for release coordination it is fine, but 
keeping development tied to this is a mistake imo. this should only direct 
when merging into master can happen, but not constrain what development is 
actually happening.

keep in mind that those who may be creating products around this software, as 
we have learned in plasma active, simply can not be tied to kde's release 
cycles. on the other hand, kde needs release cycles and can never time those 
to match every downstream's needs simultaneously (there are too many 
downstream schedule conflicts and variance in needs).

> - Move to a review based workflow before hard freeze (we need gerrit).

for certain components, yes. for other non-critical ones, this will just kill 
what development efforts were put into them for no real gain.

every time we raise the bar on development, we shrink the pool of people who 
will engage.

so i'm 100% supportive of the idea to ensure core components are more stable 
and purposefully developed and less chaotic, but would like to see a process 
that keeps additional components more freely developed.

> - Once we are on hard freeze, open merge for everyone so we can
> continue fixing things easily.

review is also important here, of course, as fixes can (and sometimes do) break 
things. that said:
 
> things we have right now and it will allow us to explore the benefits
> of the merge based workflow.

this is what really piques my interest: merge based workflow.

an integration branch would be fantastic. that branch should rebase 
periodically off of master and only be used to merge feature branches. this 
branch would largely take the place of current master: where development 
"happens". feature branches should be merged into integration on a regular 
basis and developers and testers should track this integration branch in their 
day-to-day usage

integration should always be open to feature branch merging. master should 
only be open for feature merge when not in freeze, however.

when in freeze, either a stabilization branch could be made off of master for 
this purpose (probably a very good idea for larger fixes) which is then merged 
down in master at known good points .. or .. master is opened for bug fixes 
directly in those periods. the latter is probably not as "good" from a 
stability POV, but may be more reasonable and less of a workload for people 
doing the actual work.

so what i'm interested in hearing is what sort of branch management scheme 
would work for people. i'm happy to maintain either an integration or the 
master branch (but not both).

in any case, i'm personally less interested about the details of the review 
process (many different ways to do that) and more interested in the branching 
strategy.

note that the methods being (slowly) adopted for frameworks devel are also 
moving in the direction noted above.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120314/3372c062/attachment.sig>