Hi
So here a little recap where we are as the date of today,
and a few suggestions to enhance the cooperation workflow through gerrit
and build/publish system.
### WAITING TO BE MERGED BY MAINTAINER : CR+2 and V+1 ###
At this time there are a dozen changes which could be mergeable now :
https://review.tizen.org/gerrit/#/q/label:Code-Review%253D%252B2++AND+verified%253D1+AND+status:open,n,z
This amount is pretty good, and except a few ones this look like normal
development process...
Note older one is from Sept 2013.. and still not merged , how comes ?
(ie: https://review.tizen.org/gerrit/#/c/9893/ )
If it's not relevant anymore should it be abandoned ?
or at least give some reason in comments why it should remain there...
### WAINTING TO BE VERIFIED ###
Over 50 changes are reviewed (CR+2) but not Verified
https://review.tizen.org/gerrit/#/q/label:Code-Review%253D%252B2++AND+status:open,n,0029398d00002915
Seems the Verified status is unclear and should be clarified if it is
optional or not ?
I understand it as someone should just pull the change and check it does
what is supposed to do.
But who is in charge of doing this ?
Should the patch submitter be allowed to self verify it ?
### COULD BE MERGED (CR+2) BY INTEGRATOR ###
About 100 changes could be merged by Integrators
since they got positive review from the community (CR+1)
but miss a CR+2 from maintainers even after a 48h delay.
https://review.tizen.org/gerrit/#/q/label:Code-Review%253D%252B1+AND+NOT+label:Code-Review%253D-1+AND+NOT+label:Code-Review%253D-2+status:open,n,z
Note it has been said since Tizen moved to open governance,
that a couple of day delay was allowed for maintainers to give feedback
on change,
once delay expired the change has positive review (CR+1) then it could
be merged by Integrator...
I think this last point could be improved if we have more Integrators
(who can merge changes),
### WAITING TO BE REVIEWED ###
Over 250 changes are not reviewed at all (note some have Verified+1 status)
https://review.tizen.org/gerrit/#/q/label:Code-Review%253D%252B1+AND+NOT+label:Code-Review%253D-1+AND+NOT+label:Code-Review%253D-2+status:open,n,z
This means everyone should take a little time to help shrinking this
list, or abandon irrelevant changes
Or maybe we could have more assigned reviewers per package,
ie, qt developer Tomasz Olszak is doing this w/ me as reviewer and the
integration seems working,
so I think this is a good pattern to replicate.
### NEED TO SUBMIT TO BUILD AND PUBLISH IN REPOS ###
This topic is also important, because if the change was merged through
gerrit,
it does not mean it is actually published ...
and requiere some deep investigation to know why it wasnt released
or if it was even submitted (by maintainer)...
On my previous project we allowed developer to submit the build themselves
once the (their) changes files was merged and yes it was mandatory to
push it.
Note that could tracked easily if each change where associated to a BugId ,
then as long as the change is not released the bug would remain open in
jira...
( head to previous discusion
https://lists.tizen.org/pipermail/dev/2014-January/001493.html
and https://wiki.tizen.org/wiki/Talk:Packaging/Guidelines )
As an example you can see a change without associated bug which has been
merged but not published
(not on Tizen Infrastructure) :
https://review.tizen.org/gerrit/gitweb?p=platform/upstream/wpa_supplicant.git;a=commit;h=5bbe11735cdda316043469feebe5f18f17cced4f
https://review.tizen.org/gerrit/gitweb?p=platform%2Fupstream%2Fwpa_supplicant.git;a=summary
### TRACKS FOR IMPROVEMENTS ###
I feel we're lacking maintainers,
so co-maintainance would makes sense to get a smoother workflow...
Wouldn't it makes sense that those who do good commits and/or good
review are able
to do the integrator job
(this mean doing the maintainer role, once the maintainer did not give
feedback on the change
after a time period) ? If yes how to set it up ? (touching scm/meta/git
project?)
If you feel this topic need more explanation, I can try to do my best to
help the tizen project
Also find me in couple of days at FOSDEM, I'll be presenting something
about "Contributing to Tizen"
and also can talk more about after around a cold beer or warm coffee...
A few links
* https://wiki.tizen.org/wiki/OSDev/Work_flow
* https://wiki.tizen.org/wiki/Tizen_Code_Review#Code_review_guidelines
*
https://source.tizen.org/documentation/developer-guide/submitting-and-reviewing-on-gerrit-and-obs
* http://www.tizenexperts.com/2014/01/tizen-talks-fosdem-2014/
Thank you for reading and carring !
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
