On Thu, Dec 6, 2012 at 1:04 PM, Matthew Miller 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
>> suitable than Bugzilla -
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 patch
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 featu
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 :)
https://fedorahosted.org/fesco/tic
- 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 sugge
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 trac
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/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 po
* 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
https://admin.fedora
> 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 down
> 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:
> > htt
> 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
> > som
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 al
On 12/01/2012 02:26 AM, Adam Williamson wrote:
On Fri, 2012-11-30 at 12:21 -0500, Matthew Miller wrote:
On Thu, Nov 29, 2012 at 05:42:15AM -0500, Marcela Maslanova wrote:
I think we do need more clarity on "system-wide/defaults changing
features or critical path components". What's the threshol
Dne 30.11.2012 18:16, Matthew Miller napsal(a):
On Fri, Nov 30, 2012 at 03:28:52PM +0100, Vít Ondruch wrote:
I'd love to see the feature process to be turned opposite, i.e. make
the feature auto-approved as default. It could look like:
In general, features _have_ been approved by default, so in
On Fri, 2012-11-30 at 12:21 -0500, Matthew Miller wrote:
> On Thu, Nov 29, 2012 at 05:42:15AM -0500, Marcela Maslanova wrote:
> > > I think we do need more clarity on "system-wide/defaults changing
> > > features or critical path components". What's the threshold for
> > > defaults? (LVM, for a spe
On Thu, Nov 29, 2012 at 05:42:15AM -0500, Marcela Maslanova wrote:
> > I think we do need more clarity on "system-wide/defaults changing
> > features or critical path components". What's the threshold for
> > defaults? (LVM, for a specific example.) What's the threshold for a
> > change to a critic
On Fri, Nov 30, 2012 at 03:28:52PM +0100, Vít Ondruch wrote:
> I'd love to see the feature process to be turned opposite, i.e. make
> the feature auto-approved as default. It could look like:
In general, features _have_ been approved by default, so in practice, this
isn't a major change. It partic
On Fri, Nov 30, 2012 at 04:31:51PM +0100, Miloslav Trmač wrote:
> > I think we do need more clarity on "system-wide/defaults changing features
> > or
> > critical path components". What's the threshold for defaults? (LVM, for a
> > specific example.) What's the threshold for a change to a critical
On Thu, Nov 29, 2012 at 10:50 AM, Richard W.M. Jones wrote:
> Well fair enough, but at the moment these have to go through the
> feature process, which is extremely cumbersome for a routine upgrade.
>
> Take a look at:
>
> https://fedoraproject.org/wiki/Features/GHC741
>
> That's a huge amount of
On Thu, Nov 29, 2012 at 1:21 AM, Matthew Miller
wrote:
> I think we do need more clarity on "system-wide/defaults changing features or
> critical path components". What's the threshold for defaults? (LVM, for a
> specific example.) What's the threshold for a change to a critical path
> component?
Hello,
On Thu, Nov 29, 2012 at 12:32 AM, "Jóhann B. Guðmundsson"
wrote:
> Lacks clarification on what's considered an feature.
The proposal continues to use the current wide definition - it only
treats some differently.
> Arguably it should be mandatory for feature owners to provide or work with
Dne 28.11.2012 21:08, Miloslav Trmač napsal(a):
Hello,
this proposal was recently linked in various places, so let's formally
introduce it:
https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
This an incremental change, not a major overhaul designed to solve all problems.
The benefits
On Thu, 2012-11-29 at 05:38 -0500, Marcela Maslanova wrote:
> > Lacks clarification on what's considered an feature.
> >
> > Arguably it should be mandatory for feature owners to provide or work
> > with the documentation and or marketing communities documenting and
> > publishing what benefits c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Nov 29, 2012 at 08:31:25AM -0700, pete wrote:
> It's actually 'fedora_requires_release_note' - you can find it with the
> other, more familiar tags.
>
> The response from Chris reminded me of the value of brevity, so I'll add
> one comment b
On Wed, 2012-11-28 at 16:03 -0600, Bruno Wolff III wrote:
> On Wed, Nov 28, 2012 at 15:01:21 -0700,
> >
> >There are several mechanisms for a developer to get their work into the
> >release notes. The rel-notes BZ tag was wholly unused during this cycle, to
> >the best of my knowledge. There were n
- Original Message -
> From: "Richard W.M. Jones"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, November 29, 2012 10:50:48 AM
> Subject: Re: RFC: Feature process improvements
>
> On Wed, Nov 28, 2012 at 03:56:04PM -0600
- Original Message -
> From: "Matthew Miller"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, November 29, 2012 1:21:01 AM
> Subject: Re: RFC: Feature process improvements
>
> On Wed, Nov 28, 2012 at 09:08:59PM +0100, Mi
- Original Message -
> From: "Jóhann B. Guðmundsson"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, November 29, 2012 12:32:35 AM
> Subject: Re: RFC: Feature process improvements
>
> On 11/28/2012 08:08 PM, Miloslav Trmač wrote:
> > Hello,
> &
On Wed, Nov 28, 2012 at 03:56:04PM -0600, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones said:
> > > * Simplifying the process for self-contained features (e.g. individual
> > > package version upgrades)
> >
> > I don't see why these are features at all. Surely it's better towards
> >
I would suggest that we create a clear SOP for fall back planning in case
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
somethi
On Wed, Nov 28, 2012 at 09:08:59PM +0100, Miloslav Trmač wrote:
> this proposal was recently linked in various places, so let's formally
> introduce it:
> https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
As discussed earlier, I liked the three-tier approach better, but I'm in
favor of
On Wed, Nov 28, 2012 at 09:23:09PM +, Richard W.M. Jones wrote:
> > * Simplifying the process for self-contained features (e.g. individual
> > package version upgrades)
> I don't see why these are features at all. Surely it's better towards
> the end of each release cycle for someone to compar
On 11/28/2012 08:08 PM, Miloslav Trmač wrote:
Hello,
this proposal was recently linked in various places, so let's formally
introduce it:
https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
This an incremental change, not a major overhaul designed to solve all problems.
The benefits ex
On Wed, Nov 28, 2012 at 15:01:21 -0700,
There are several mechanisms for a developer to get their work into the
release notes. The rel-notes BZ tag was wholly unused during this cycle, to
the best of my knowledge. There were no bugs filed against the
release-notes bugzilla product to request inc
> I don't see why these are features at all. Surely it's better towards
> the end of each release cycle for someone to compare the versions of
> packages and add something in the release notes for each major GUI /
> programming language / user application that got a big update.
>
> Rich.
>
I only
Once upon a time, Richard W.M. Jones said:
> > * Simplifying the process for self-contained features (e.g. individual
> > package version upgrades)
>
> I don't see why these are features at all. Surely it's better towards
> the end of each release cycle for someone to compare the versions of
> p
It's not clear where this should be discussed? Editing the wiki talk
page? On this list?
Anyway, I'll kick this off by saying:
> * Simplifying the process for self-contained features (e.g. individual
> package version upgrades)
I don't see why these are features at all. Surely it's better tow
Hello,
this proposal was recently linked in various places, so let's formally
introduce it:
https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
This an incremental change, not a major overhaul designed to solve all problems.
The benefits expected from this proposal:
* Making proposed fea
40 matches
Mail list logo
