FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-09-2008, 11:33 PM
John Poelstra
 
Default new RPM version and Feature process

Thorsten Leemhuis said the following on 07/09/2008
But this announcement made me wondering: We have a big and complicated
Feature process [1] in Fedora that keeps a whole lot of people and
committees (especially FESCo) busy. Afaics the new RPM version is
something that can be considered a "feature" [2]. It was afaics not
approved yet by FESCO [3] or even proposed [4]. I would expect going
backwards to an older RPM in rawhide later will be next to impossible or
very very hard. IOW: once it's in rawhide for a few days FESCO kind of
has no other chance then to approve this feature, in case it ever comes
up for a Feature vote in a FESCo meeting.


Just because something is in rawhide does not force FESCo's hand to
accept (note that is "accept" not "approve") the feature page, thus
officially advertising it as a feature of our next release.


I agree the feature process is not perfect and we have tried to keep it
as un-cumbersome as possible--which is why there is no blocking on
getting FESCo acceptance to be added to rawhide, etc. Just last week we
completed our second public review of the process which sadly only had
suggested changes by three people.


http://fedoraproject.org/wiki/Features/F10PolicyReview



So is the most of the Feature process (and especially FESCo's approval)
useless overhead? It looks to me that the answer tends to be "yes" as
long as big features like this can easily creep in without going through
the established approval process, as long as the feature gets added to
rawhide early enough in the devel cycle.


I think you've overlooked some of its benefits:
http://fedoraproject.org/wiki/Features/Policy#Background


including the HUGE amount of equivalent marketing dollars the pages help
drive which Paul mentioned at FUDCon.


I'd argue the return on investment is there.

Just wondering. No, I really don't want to stop the new RPM; there are
likely other examples (say OpenOffice 3.0) in rawhide (but going
backwards there as hard as with RPM). But I'm more and more wondering if
the complex Feature process is worth all the trouble and effort. The
best thing that came out of it in F9 IMHO were the good release notes
and great "whats new" pages. But I'd say we can have that easier.


I'm all ears. What are your specific ideas for a more effective process
so it is worth all the "trouble and effort"?


We've spent a lot of time up until now trying to get to a useful
process, including the public reviews of the process we have at the
start of each release. More participation and concrete suggestions from
people like you would be greatly appreciated


John

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-09-2008, 11:41 PM
"Paul W. Frields"
 
Default new RPM version and Feature process

On Wed, 2008-07-09 at 16:33 -0700, John Poelstra wrote:
> Thorsten Leemhuis said the following on 07/09/2008
> > So is the most of the Feature process (and especially FESCo's approval)
> > useless overhead? It looks to me that the answer tends to be "yes" as
> > long as big features like this can easily creep in without going through
> > the established approval process, as long as the feature gets added to
> > rawhide early enough in the devel cycle.
>
> I think you've overlooked some of its benefits:
> http://fedoraproject.org/wiki/Features/Policy#Background
>
> including the HUGE amount of equivalent marketing dollars the pages help
> drive which Paul mentioned at FUDCon.
>
> I'd argue the return on investment is there.

On top of the measurable part, there were a very large proportion -- I'd
say it was fully half, out of more than a dozen interviews I gave for
the Fedora 9 release -- where journalists asked direct questions about
specific features. They almost always prefaced it by saying, "I read
the feature pages on the wiki, which were really good. I was hoping you
could explain further...".

> > Just wondering. No, I really don't want to stop the new RPM; there are
> > likely other examples (say OpenOffice 3.0) in rawhide (but going
> > backwards there as hard as with RPM). But I'm more and more wondering if
> > the complex Feature process is worth all the trouble and effort. The
> > best thing that came out of it in F9 IMHO were the good release notes
> > and great "whats new" pages. But I'd say we can have that easier.
>
> I'm all ears. What are your specific ideas for a more effective process
> so it is worth all the "trouble and effort"?
>
> We've spent a lot of time up until now trying to get to a useful
> process, including the public reviews of the process we have at the
> start of each release. More participation and concrete suggestions from
> people like you would be greatly appreciated


--
Paul W. Frields
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-09-2008, 11:44 PM
"Jeff Spaleta"
 
Default new RPM version and Feature process

On Wed, Jul 9, 2008 at 3:33 PM, John Poelstra <poelstra@redhat.com> wrote:
> We've spent a lot of time up until now trying to get to a useful process,
> including the public reviews of the process we have at the start of each
> release. More participation and concrete suggestions from people like you
> would be greatly appreciated


I think the next big return on investment outside of with regard to
feature tracking is going to involve the maturation of some of the
ideas and tools the QA people are playing with. I don't completely
get everything that a usable testopia will do for us as a project..but
I have a sense that once we gain some communal experience using it, if
we can tie it into the Feature process its going to magnify the value
of the Feature process significantly.

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-10-2008, 02:54 AM
Matthias Clasen
 
Default new RPM version and Feature process

On Wed, 2008-07-09 at 16:33 -0700, John Poelstra wrote:

>
> I'm all ears. What are your specific ideas for a more effective process
> so it is worth all the "trouble and effort"?
>
> We've spent a lot of time up until now trying to get to a useful
> process, including the public reviews of the process we have at the
> start of each release. More participation and concrete suggestions from
> people like you would be greatly appreciated
>

Here are some comments on my recent experience with the feature process:

I've just 'gotten back' a ton of feature pages with the comment 'please
complete section a, b, c...' - but there is no definition anywhere of
what each section is supposed to contain, so how can I know what
'complete' means ?

So, I have to fly blind and put something in each section in the hope
that it passes the next time. But it feels like there is a lot of
overlap between the (undefined) topics on the feature template:
If I've already filled out the 'detailed description', why am I asked to
provide more details in the 'summary' ? And if I've already listed a ton
of packages that need changes under 'scope', whats supposed to be put in
'dependencies' ? etc...

In general, I think this whole process might be more pleasant if it felt
less like writing a paper and getting it graded and more like a
collaborative process. E.g. if instead of 'please complete the user
experience section' I got some questions back like: 'I didn't quite
understand how to turn this on, will there be a menu item ?', 'does this
also require changes to package foo ?'.

Matthias

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-10-2008, 08:31 PM
John Poelstra
 
Default new RPM version and Feature process

Matthias Clasen said the following on 07/09/2008 07:54 PM Pacific Time:

On Wed, 2008-07-09 at 16:33 -0700, John Poelstra wrote:

I'm all ears. What are your specific ideas for a more effective process
so it is worth all the "trouble and effort"?


We've spent a lot of time up until now trying to get to a useful
process, including the public reviews of the process we have at the
start of each release. More participation and concrete suggestions from
people like you would be greatly appreciated




Here are some comments on my recent experience with the feature process:

I've just 'gotten back' a ton of feature pages with the comment 'please
complete section a, b, c...' - but there is no definition anywhere of
what each section is supposed to contain, so how can I know what
'complete' means ?


Fair enough. I believe in most cases requested information was for
sections that were completely blank. Up until now I thought the section
headings were self-explanatory--I believe you are the first to raise
this point about needing definitions, which we can definitely address.
I hope people will read them.



So, I have to fly blind and put something in each section in the hope
that it passes the next time. But it feels like there is a lot of
overlap between the (undefined) topics on the feature template:
If I've already filled out the 'detailed description', why am I asked to

provide more details in the 'summary' ? And if I've already listed a ton
of packages that need changes under 'scope', whats supposed to be put in
'dependencies' ? etc...


Good point. I can see where defining the sections would help for these.
In terms of requesting more for the summary--that information gets
listed on the overal summary page for all features so I thought it would
be helpful to readers of the summary page if the summary for that
particular features was more descriptive and talked in less technical
terms.




In general, I think this whole process might be more pleasant if it felt
less like writing a paper and getting it graded and more like a
collaborative process. E.g. if instead of 'please complete the user
experience section' I got some questions back like: 'I didn't quite
understand how to turn this on, will there be a menu item ?', 'does this
also require changes to package foo ?'.


I agree that doesn't sound like fun and I apologize if that is how the
reviews have come across. I confess that in most cases I don't have the
full technical background or understanding of the feature (another
reason why FESCo reviews them) to know whether information in one
section of the form supplements another or appropriate technical issues
that should be raised. In most cases I'm just trying to do a high level
review to make sure the feature page is complete so that when FESCo
reviews them it isn't a waste of their time as it was in the past when
key sections of the form were blank and it had be discussed again at the
next meeting. The feature policy does state this as a requriement,
though I understand better now where you are coming from.


The more positive collaborative process you are suggesting--which
parties would that be between?


Thanks for your feedback
John

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-11-2008, 03:30 PM
Matthias Clasen
 
Default new RPM version and Feature process

On Thu, 2008-07-10 at 13:31 -0700, John Poelstra wrote:

> Fair enough. I believe in most cases requested information was for
> sections that were completely blank. Up until now I thought the section
> headings were self-explanatory--I believe you are the first to raise
> this point about needing definitions, which we can definitely address.
> I hope people will read them.

Thanks, I believe it really will help. Also keep in mind that not
everybody who writes a feature page is a native speaker, so what is
self-explanatory and obvious to you may look different when you come
from another culture...

>
> > So, I have to fly blind and put something in each section in the hope
> > that it passes the next time. But it feels like there is a lot of
> > overlap between the (undefined) topics on the feature template:
> > If I've already filled out the 'detailed description', why am I asked to
> > provide more details in the 'summary' ? And if I've already listed a ton
> > of packages that need changes under 'scope', whats supposed to be put in
> > 'dependencies' ? etc...
>
> Good point. I can see where defining the sections would help for these.
> In terms of requesting more for the summary--that information gets
> listed on the overal summary page for all features so I thought it would
> be helpful to readers of the summary page if the summary for that
> particular features was more descriptive and talked in less technical
> terms.

See, there you already have a great start for a one-paragraph
explanation of what the summary is all about...


> The more positive collaborative process you are suggesting--which
> parties would that be between?

>From the parties who would benefit from having the relevant sections
fille out, I guess. E.g. I would expect some pointed questions from QA
for better test cases, and questions from the docs guys about release
notes.

Of course, that is much easier later on, when the stuff is already in
rawhide and the 'other parties' can just play around with it...

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 09:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org