Yes, you will still need BMC #'s.
If in the progress of your development you discover a bug that QA hasn't
found yet then just create a new bug entry yourself.
--rusty
On 06/11/2011 08:35 AM, Dumez, Christophe wrote:
Hi,
Just to be sure: Now that packages such as qtcontacts-eds are present
in MeeGo:1.2:oss:Testing, do I still need a BMC# to SR an update?
For example, if I fix a bug that was not reported or if I implement a
new feature, am I expected to file a bug report myself before SRing?
TIA,
Chris.
On Fri, Jun 10, 2011 at 10:54 PM, Patrick Ohly<[email protected]> wrote:
On Fr, 2011-06-10 at 16:14 +0100, Lynch, Rusty wrote:
On 06/10/2011 04:00 AM, Patrick Ohly wrote:
On Do, 2011-06-09 at 19:03 +0100, Zhu, Peter J wrote:
Seem we should set a devel project for all these packages as eds since
all the new stuff including eds/syncevolution are now submitted
directly from there. I do see some guys have submissions for the
packages, you don't want them to clob your changes :-). Are you ok?
I had already requested a devel project for EDS
(https://bugs.meego.com/show_bug.cgi?id=17355) and Anas created the
"eds" project for us in response. The intention was to use that for
anything related to the EDS migration and potentially future
maintenance/testing of related packages.
It got a bit confusing during my vacation when we were asked to also put
these packages into devel:meego-ux. I'm not sure whether we really want
them there.
Regarding SyncEvolution, it is now maintained in "eds".
The meego-ux is being maintained in devel:meego-ux, and since we have
several packages that need to test against the latest greatest
unreleased eds then these need to be pulled into devel;meego-ux. This
is doens't mean that devel:meego-ux somehow takes over maintaining the
eds packages.
Okay, that makes sense to me.
Also... instead of copying the packages over with a sr, you will make
your life much easier by just making a link. That way you only have to
update the package in the eds project.
I already created such a link for SyncEvolution. I did it via the web
interface and - if memory doesn't fail me (so much done, so much to
remember... I start to swap out into /dev/null..) - disabled the
automatic updating of the devel:meego-ux repo from "eds". That way we
can try out experimental changes in "eds" before promoting to
"devel:meego-ux".
I suggest we do the same for the other packages which need to trickle
from "eds" to "devel:meego-ux". From there we can SR into Trunk and the
1.2 branch.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging