On 12/06/2012 12:50 PM, Vít Ondruch wrote:
Dne 6.12.2012 10:14, Panu Matilainen napsal(a):
On 12/05/2012 09:38 PM, Matthew Miller wrote:
One approach: a convention where each feature gets a tracking bug,
and then
various tasks can be marked as blocking that. *Then*, each release
can have
a tracking bug for accepted features themselves, and the tool to
produce the
chart can simply be pointed at that and follow the tree downward.
Trackign them in bugzilla makes so much sense and seems so blatantly
obvious now that you said it... its kinda hard to understand why that
hasn't been done from the start. Please make it so :)
- Panu -
Don't think it makes more sense then the percentage in wiki. I remember
migration from Ruby 1.8.7 to Ruby 1.9.3. We needed to adjust every ruby
package in fedora and rebuild them. Some of them were piece of cake,
some needed patches, other packages needed to be retired and some of
them replaced. Not sure how could bugzilla provide better estimates.
Even tracking of this issues in BZ would be significant overhead.
I dont see anybody suggesting tracking a feature requiring mass-rebuilds
on single package level. If a feature requires substantial
mass-rebuilds, then the mass-rebuild tracker might be *one* bug where
the mass-rebuild progress is tracked, and on which the feature depends.
And hard-to-resolve rebuilds which require significant extra work could
be tracked in their own bugs which in turn block the main mass-rebuild
bug. Or something like that.
As the current feature percentage meter means absolutely nothing at all,
its kinda hard to do worse than that :)
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
