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
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,
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
- Original Message -
On Wed, Nov 28, 2012 at 09:39:03PM -0500, John Dulaney wrote:
a feature, especially a crit path feature, is not ready for prime
time.
Obviously, if a feature is not %100 by feature freeze, then it
needs to be
dropped. I would even venture to suggest that we
On Thu, Dec 06, 2012 at 11:14:19AM +0200, Panu Matilainen wrote:
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 :)
On Thu, Dec 06, 2012 at 08:11:01AM -0500, Jaroslav Reznik wrote:
At FUDCon Milan, we discussed using Trac to manage Spin process - it's
actually very similar process. And for tracking stuff I think it's more
suitable than Bugzilla - custom states, better overviews + use Wiki just
for feature
On Thu, Dec 06, 2012 at 11:50:01AM +0100, Vít Ondruch wrote:
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,
On Thu, Dec 6, 2012 at 1:04 PM, Matthew Miller mat...@fedoraproject.org wrote:
On Thu, Dec 06, 2012 at 08:11:01AM -0500, Jaroslav Reznik wrote:
At FUDCon Milan, we discussed using Trac to manage Spin process - it's
actually very similar process. And for tracking stuff I think it's more
On Wed, Nov 28, 2012 at 09:39:03PM -0500, John Dulaney wrote:
a feature, especially a crit path feature, is not ready for prime time.
Obviously, if a feature is not %100 by feature freeze, then it needs to be
dropped. I would even venture to suggest that we include in the SOP
something along
On Wed, Dec 05, 2012 at 08:19:15PM +0100, Fabian Deutsch wrote:
I like burndown charts. Low overhead, easily read, and generally more
concrete than guesses at percentage done. I wonder if there's a way we can
easily provide a widget in the wiki for keeping them up to date. This:
On Wed, Dec 05, 2012 at 08:19:15PM +0100, Fabian Deutsch wrote:
I like burndown charts. Low overhead, easily read, and generally more
concrete than guesses at percentage done. I wonder if there's a way we can
easily provide a widget in the wiki for keeping them up to date. This:
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
* Rahul Sundaram [06/12/2012 00:39] :
Yeah. This makes sense. Wiki for tracking isn't a bright idea really.
And the time-tracking is already built in to bugzilla so most of the code
needed is already written.
Emmanuel
--
devel mailing list
devel@lists.fedoraproject.org
13 matches
Mail list logo
