Re: RFC: updated workflow [WAS: Re: git+patch workflow]


>  - after some testing  the branch with patch will deleted (and the
>  ticket is closed)
>  - if testing fail, create new branch with patch... hm, need to discuss
> this situation.
See below my suggestion.
> > This is pretty much the old stuff above (now we create a branch for every
> > ticket (proposed branchname 1234_something_describing).
> BTW, may be a situation in which no one askes for the patch (no time or
> busy, lazy, don't want to take responsibility for the consequences of a
> patch, etc). What do in this case?
Well.. if this will be the case in the future we have to rethink the idea.. 
but until at least 3 people are more or less active this shouldn't happen.
> And what do if no testing reports? Is ticket leave in 'always testing'
> stage?

Okay to fasten the process a bit up:
 - if a ticket contains a patch the acceptor of this ticket create a branch 
with this patch applied 
 - people can test it there and comment in this ticket
 - if they have an enhancment they can fix it in git (and push it to the server 
of course ;-)) and add a updated patch (for tracking the issue) to the 
bugreport. If the patch in it's latest version is acked the branch get merged 
back into the master branch. Then we have only one ack step and not two 

Now, how to handle the ticket states with this workflow:
After a ticket is created it is new.. When someone accepts it it is set to 
accepted. When someone has a patch which is worth to be added to a git branch, 
this should be done. Then the ticket can be set to testing as this is 
currently the case (We test if the patch is okay). If two people acked the 
patch (they really should test it and not only look on the sourcecode), the 
branch with the fix inside will be merged by the acceptor of the ticket this 
branch belongs too, into master. Then the ticket will be set to closed.

The same if we develop after 4.6.2 own new stuff: 
 A ticket is opened with the idea inside... Someone develops a new feature 
based on master in a  branch. After he thinks that this task is done he adds a 
patch to the report and set the report to testing. Then someone can look at 
his work  and comment in the ticket. After the patch is fine this branch get 
merged into master (and the ticket is closed).

Hope this helps to make it someone easier.


 . '' ` .   Patrick Winnertz <winnie debian org>
:  :'   :   proud Debian developer, author, administrator, and user
`. `'` -
  `-  Debian - when you have better things to do than fixing systems

Attachment: signature.asc
Description: This is a digitally signed message part.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]