On 23/12/10 22:39, David Greaves wrote:
On 21/12/10 08:19, Carsten Munk wrote:
Well, and we're side-stepping program management totally by having those
dummy bugs. A new package should be a FEA# and approved by program
management as per
http://wiki.meego.com/Release_Engineering/Process#Package_quality_expectations_for_submissions_into_.2A:Testing_projects
Either we start enforcing it for everything or we have to modify the
rules
to fit reality... Proposals welcome?
Is it reasonable to say that:
"In principle every change should be fixing a bug or contributing to a
feature"
This means we accept that MeeGo is not a free-for-all but is actually aimed at
being a tight distro that commercial and open vendors can use to deliver
consumer level quality products?
So I think part of the problem is that this process has :
Bug or Feature referenced must have proper values in following fields:
* Status = RESOLVED
* Version = MeeGo release to which item is targeting
* Target Build = MeeGo weekly build to which item is targeting
This implies that every changelog entry must RESOLVE a bug (almost OK) or a
feature (not OK).
It seems to me that a FEA# should cover development work that moves towards some
functional spec. It is likely to be referenced in several packages and in
several changelog entries.
So I suggest we define the mention of an FEA# in a changelog entry as meaning
"contributes to" rather than RESOLVEs. This allows FEA like:
* Track upstream
* Support harware X
(Naturally some packages like gstreamer wouldn't just get given a "track
upstream" FEA - API breakage is too risy.)
As a manager looking at these features and deciding if it is 'complete' I would
like to easily filter all the changelog entries that mention my feature. I'd
like to see if there's been anyone working on it. As a develope I'd like to see
if anyone is working on a FEA in the same area (eg in an FEA tree). This stuff
is important to communication in a distributed team. It's also important to
people watching - both MeeGo insiders and those who are our customers.
Back to bugs: a few weeks back I saw Auke post a change which contributed to a
bug but didn't fix it; some bugs need changes to multiple packages and will only
happen over time.
It then may make sense to add a little wording prior to the bug# :
(PARTIAL FIX BMC#3433)
which may help both QA and future debugging activity (as well as automation).
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
