I'm fine with that definition. Only one additional suggestion: let's define max time for that package to be in pending state. :build project is affecting other new submissions, so even there keeping something not so good for more than day or two would be counterproductive IMHO.
br, Alexander (mobile)
> On 18 Oct 2013, at 19:26, "Lynch, Rusty" <rusty.lynch at intel.com> wrote:
>> Let me clarify... I am requesting RE to allow a SR to just sit in a
> pending state if the package does not build. I am not asking that we
> accept the broken package, but to just let it spend some time in the
> build project waiting on another package's SR to come in and fix
> building of both packages in the build project.
>> Once a package successfully builds in the build project, then it can be
> accepted.
>> --rusty
>> On Fri, 2013-10-18 at 02:00 -0700, Liu, Bing Wei wrote:
>> The key point here is that RE should reject SRs with good reasons and
>> communicate with related package maintainers timely. Rusty can share
>> more backgrounds about how this caused issues on IVI side.
>>>> - Bingwei
>>>>>>>>>> From: Kanevskiy, Alexander
>> Sent: Friday, October 18, 2013 4:11 PM
>> To: Liu, Bing Wei; Lynch, Rusty; Karur Mohan, Prajwal; Saxena, Sunil;
>> Michael Kim; jinkun.jang at samsung.com; ANUJ MISHRA; ???; Dong, Junfeng
>> Cc: Tizen Dev
>> Subject: Re: [Dev] Notes of 3.0 Trunk taskforce meeting (Oct. 18)
>>>>>>>>>> One note about: "Release engineers should not simply decline SRs
>> because of building issues. Sometimes several SRs should be accepted
>> together to function".
>>>>>> It is true that some components must be accepted together to get
>> it build able.
>>>>>> However, it's not reasonable to accept something that _right now_ for
>> sure does not build. There is no value in that.
>>>>>> If we have several components that needs to be integrated together,
>> they should be submitted _together_.
>>>>>> Otherwise, we are back to square one and we will be in the same shape
>> as today – project with many unbuilt packages.
>>>>>>>>>>>>>>>>>> On 10/18/13 09:58, "Liu, Bing Wei" <bing.wei.liu at intel.com> wrote:
>>>>>>>>>>>> • Why the daily meeting - already elaborated in Rusty's
>> email below
>>>>>> • Roles in the taskforce
>>>>>> • Mobile leads: Jerry Ju (Samsung), Junfeng Dong
>> (Intel)
>>>>>> • IVI lead: Rusty Lynch (Intel)
>>>>>> • BRO leads: Jinkun Jang (Samsung), Praj M.
>> Karur / Jian-feng Ding (Intel)
>>>>>> • Goals of the taskforce
>>>>>> • Mobile: basically functional images (OSP & Web
>> apps can launch)
>>>>>> • IVI: back to normal, esp. able to run web
>> runtime as before
>>>>>> • Standing agenda
>>>>>> • Raise blocker issues
>>>>>> • Report-out from Mobile leads / IVI lead
>>>>>> • What have been fixed since the last
>> meeting
>>>>>> • What fixes are pending for gerrit
>> review, or merge, or gbs submission, or OBS acceptance
>>>>>> • What issues are still outstanding
>>>>>> • Report-out from BRO leads
>>>>>> • Mobile/IVI image quality status
>>>>>> • Which packages were rejected or revoked
>> and why
>>>>>> • Meeting frequency
>>>>>> • Continue to meet everyday next week and change
>> the frequency based on progress
>>>>>> • Pattern issues
>>>>>> • Release engineers should not simply decline SRs
>> because of building issues. Sometimes several SRs should be
>> accepted together to function
>>>>>> • When forking a common package to profile
>> specific and add new APIs, other common packages should not
>> call the new APIs only provided by the profile specific
>> package
>>>>>> • Maintainers should review pending patches
>> actively and remember to merge and "gbs submit" because only
>> maintainers have the access right to do so.
>>>>>> • Too many backend emails sent to maintainers,
>> which overwhelm the real valuable reminder that call for
>> maintainers' actions -- need BRO team to provide a better
>> solution
>>>>>> • Outstanding issues
>>>>>> • Mobile
>>>>>> • gcc change yesterday caused the build
>> issues of gdb (need re-trigger gdb build)
>>>>>> • wrt failed to build (calling for an API
>> that does not exist)
>>>>>> • some OSP packages have build failure
>>>>>> § - Looks link build issue again that happened
>> to other OSP packages before
>>>>>> § - cannot be reproduced in local build
>>>>>> § - someone in Samsung fixed other OSP pkgs by
>> modifying pkgconfig
>>>>>> - should evaluate if the solution can
>> be applied to the fail OSP pkgs; Junfeng to follow up
>>>>>> • IVI
>>>>>> • wrt-installer requires for
>> osp-installer
>>>>>> • Rusty encountered some segfaults in the
>> image that may hit mobile soon. Rusty will report out offline
>>>>>> • Issue tracking method
>>>>>> • Always file outstanding issues on tizen.org
>> JIRA
>>>>>> • Content issueà Tizen Release
>> (https://bugs.tizen.org/jira/browse/PTREL)
>>>>>> • Infrastructure issues --> Tizen Infrastructure
>> (https://bugs.tizen.org/jira/browse/TINF)
>>>>>>>>>>>> Regards
>>>>>> Bingwei Liu
>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>> From: Lynch, Rusty
>>>>>>> Sent: Friday, October 18, 2013 7:58 AM
>>>>>>> To: Liu, Bing Wei; Karur Mohan, Prajwal; Saxena, Sunil;
>> Michael Kim;
>>>>>>>jinkun.jang at samsung.com; ANUJ MISHRA;주현구; Dong, Junfeng
>>>>>>> Cc: Tizen Dev
>>>>>>> Subject: Kicking off a daily report-out meeting for shared
>> Tizen 3.0
>>>>>>> components
>>>>>>>>>>> As everyone actively working on Tizen 3.0 today should know,
>> the state of
>>>>>>> shared Tizen 3.0 components is a bit of a mess today since
>> the start of
>>>>>>> merging all the Tizen 3.0 code. We will definitely seize
>> this opportunity to
>>>>>>> fine tune our process to ensure we have smother transitions
>> in the future,
>>>>>>> but for the immiedate future we need to quickly get the
>> shared packages in a
>>>>>>> functional, well known state.
>>>>>>>>>>> Agenda:
>>>>>>>>>>> * Start with a quick discussion on why we are setting up a
>> daily meeting
>>>>>>>>>>> * Define roles
>>>>>>> - Mobile Leads
>>>>>>> - IVI Leads
>>>>>>> - BRO Leads
>>>>>>>>>>> * Define what the standing agenda:
>>>>>>> - All raise any blocking issues
>>>>>>> - Mobile Leads should report out on...
>>>>>>> * List what items where fixed since the last meeting,
>> and of those what
>>>>>>> items are still:
>>>>>>> - pending gerrit reviews
>>>>>>> - merged but not submitted
>>>>>>> - submitted but not accepted in OBS yet
>>>>>>> - available in the build
>>>>>>> * List the known issues being worked and potentially
>> ask for help on
>>>>>>> those items
>>>>>>> - IVI Leads should report out on...
>>>>>>> * Follow the same reporting format as mobile, adding
>> additional items
>>>>>>> not covered along with ivi specific breakage caused by the
>> shared
>>>>>>> components
>>>>>>> - BRO Leads should report out on...
>>>>>>> * Describe the basic health of the mobile and ivi
>> images
>>>>>>> - Do we have bootable images?
>>>>>>> - Do the various prelaunch daemons run?
>>>>>>> - Can we launch web/osp/efl apps?
>>>>>>> * Report out on what packages were rejected or revoked
>> and why
>>>>>>> - Find an owner to fix the issues resulting in the
>> reject/revoke
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>> Best regards, Alexander Kanevskiy.
>>---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.