[Dev] Proper SR Comments for OBS

Łukasz Stelmach l.stelmach at samsung.com
Mon Oct 28 08:41:27 GMT 2013


It was <2013-10-25 pią 13:04>, when Kanevskiy, Alexander wrote:
> On 10/25/13 11:01 , "Łukasz Stelmach" <l.stelmach at samsung.com> wrote:
>
>>It was <2013-10-24 czw 17:59>, when Kanevskiy, Alexander wrote:
>>> On 10/24/13 10:40 , "Łukasz Stelmach" <l.stelmach at samsung.com> wrote:
>>>>It was <2013-10-23 śro 10:03>, when ANUJ MISHRA wrote:
>>>>> Dear Package Maintainers,
>>>>>
>>>>> Once you raise the SR, you should add proper & meaningful comment to
>>>>> identify the changes. Comment should reflect the purpose
>>>>> correctly. This would help Release Engineer to identify criticality
>>>>> and reason of each SR in OBS.
>>>>> For many of the SR Release Engineer cannot identify the purpose and he
>>>>> has to contact individually or trackback to identify the purpose.
>>>>>
>>>>> Going forward, if SR comment is not meaningful, I would suggest
>>>>> Release Engineer to reject those SR immediately.
>>>>
>>>>According to [1] the submission should contain updates to the changlog.
>>>>Let's make those changes visible as SR comment.
[...]
>>> So, as soon as maintainers put some meaningful comment into submit, it
>>> will be visible for release engineers.
>>
>>That is not what I meant. I, as a developer, would like to have to write
>>as little as possible. If a submit request is generated only if a tag
>>points to a commit which updates packaging/*.changes (is it so?), then
>>it means I have to update the changlog to submit package for rebuild.
[...]
>>>> [1] 
>>>>https://wiki.tizen.org/wiki/OSDev/Development_guide#How_to_trigger_submi
>>>>ssion_to_OBS
>
> Content of annotation of submit tag is put into OBS SR comments
> (regardless to which commit it points to).
> This annotation can contain different information compared to what
> supposed to be in result RPM package changelog.
> E.g. priterisation/triage information that are important for program
> management at some point, but not relevant in RPM changelog.
>
> RE do see changes in all files via web UI in OBS, including *.changes.
> It is true, that those are not visible with "osc log", however

So it is not essential to put anything interesting in the tag annotation
for the first submission of a given commit, is it?

> usage of osc in reality must be avoided except real few exceptional
> cases in RE workflow.

I beg to disagree. As much as I hated people using osc to bypass gerrit,
osc is still a 100% valid tool if one needs to do any read-only
operations: like list packages, retreive changelogs etc. It may be not
of much use for most developers, however, me and my teammates have to
work with a lot of packages from the System and Base domains and web-ui
becomes less than optimal for this. 

> I don't think there is need to re-invent wheel here.

The problem I'd like to present here is: how to make package submission
lest cumbersome. After a few weeks of fixing ARM images I find the
submission process a bottleneck. By no means I'd like to make it fully
automatic. I want it to be as little repealing as possible so people
don't hate it.

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131028/0e7e4735/attachment.sig>


More information about the Dev mailing list