Suchan,
I will take the Yocto alignment as an example as it's very close to your
need.
If you log in Tizen jira (your ID and passwd are your default Tizen ID).
You will be able to use the filter bellow.
https://bugs.tizen.org/jira/issues/?filter=14499
That filter simply list all the tasks and issues entered in Jira with
label Yocto.
Label, in jira are free text which ease grouping of activities. It's not
required but makes life easier.
If I take TC-2239 as example (makedepend: bump to version 1.0.5). You
will notice that it is listed as a feature rather than a bug. To be
honest that is a details but it help to keep our stats and the process clean
I see in the description which is was blocking the generic feature
TC-1964 (Yocto Build of Tizen). This is case for all the tasks related
to the alignment of Tizen and Yocto.
It allows, when you look at the generic feature TC-1964 to see what is
the progress of all sub tasks. In short, it creates an automatic Dashboard.
https://bugs.tizen.org/jira/browse/TC-1964
Status usage is pretty simple :
- New No one is yet assign as has looked to it.
- Accepted We have assigned someone and we should have an
estimated date for completion entered (not always the case).
- Resolved The developer has done the work and Git/Gerrit Tag
given in the comments allows to locate the work.
- Released The RE has integrated the work in the image and tests
are OK.
For more details on the feature work flow (a bit different of the
issue/bug workflow) get a look at :
https://bugs.tizen.org/jira/plugins/servlet/workflow/thumbnail/getThumbnail?workflowName=TizenTaskWorkflowSimple1&stepId=3&width=full&height=full
So in your situation, you need to create a generic Tasks which describe
what and why you need to back port 2.3 API. Ideally you want to list an
email in the public mailing list toward a discussion which has accepted
the new feature (remember a No comment on a proposition is equivalent to
a Yes: Consent is by default).
Please note that the communication on the Dev mailing list on the What
and Why has not been done yet and is urgently needed.
Then you create a (sub) task for each package which needs work to
implement your global task and you mark each of them as a blocker for
your generic Task (yes that part is a bit of a pain).
Then you follow the work flow for each sub tasks putting comment when
needed (in particular Gerrit commit ID) and change the status when
applicable.
Any one can follow your progress status by looking at the generic
feature. Once all done, mark the generic feature as Released.
If you need more help or info, please let us know.
Regards
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
Le 07/01/2015 06:57, 우수창 a écrit :
Dear Dominig,
As you've been noticed, we are merging Tizen 2.3 codes to 3.0 git repositories
to provide v2.3 APIs.
We are not familiar with the process of an open source Tizen development.
So, could you let me know the details? Are there any documents which we can
refer to?
You mentioned that we have to open a Jira ticket for each change.
Is a Jira ticket an issue which has a "Task" type in bugs.tizen.org?
There are many projects in bugs.tizen.org. Which project do we create a Jira
ticket on?
Regarding the test cases which you mentioned,
Could you give me an specific example? I tried to find an example but I can't.
If we know how QA test modules, we can provide the test cases.
Thanks,
Suchang.
------- Original Message -------
Sender : Dominig ar Foll (Intel OTC)<dominig.arf...@fridu.net>
Date : 2015-01-06 20:30 (GMT+09:00)
Title : [Dev] 2.3 API creeping in Tizen 3 requires coordination
Hello,
we noticed that several new reviews are about to get in Tizen 3 relative
to 2.3 API.
see as example (not a complete list) ;
https://review.tizen.org/gerrit/33153
https://review.tizen.org/gerrit/33151
https://review.tizen.org/gerrit/33150
https://review.tizen.org/gerrit/33111
https://review.tizen.org/gerrit/33110
While I have no principle issue against such action, I would like to see
a few action taken in order to ensure that Tizen 3 consistency is kept :
- a Jira Ticket should be open for each change required. In order to
get a full visibility of the change to come rather than to see them
commit by commit.
Preferably we should add a label to each ticket to ease filtering
(e.g. "2.3 compatibility").
Developper should mark the Jira ticket as released when his come is
merged, so that QA know that they can test it. QA should close it when
verified.
The model use to align with Yocto can be taken as example.
The goal here is to allow a global visibility on all the change to come.
I would also like to see a clear pointer toward the test cases to be
used by QA to test those new features and a communication on the mailing
list giving the list of the packages to be affected in order to warn all
developers of the change to come.
Thanks.
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
