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-07-2008, 09:45 PM
Kevin Kofler
 
Default FESCo Meeting Summary for 2008-07-03

Brian Pepple <bpepple <at> fedoraproject.org> writes:
>http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans
>http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections

Ugh, developers _already_ struggle with filling in all the sections, which
sometimes simply don't apply to the feature, how is even more bureaucracy going
to help? Let me take a past feature as an example (for lack of ability to
predict the future): try writing a complete detailed test plan for
FeatureKDE4... And no, you don't have 3 years to write it and I don't think the
wiki will scale to megabytes of text in a single feature page. ;-) And in
addition to sections just not relevant to the specific feature, there's also
the issue of developer time being wasted on bureaucracy, time which not all
developers have: the FeatureKDE4 page ended up as complete as it now is because
we spent lots of time on it, some feature pages are in a much worse state, and
I don't think pressure like the above "process improvements" is going to help,
because this isn't laziness, it's genuine lack of time.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-07-2008, 11:27 PM
Matthias Clasen
 
Default FESCo Meeting Summary for 2008-07-03

On Mon, 2008-07-07 at 21:45 +0000, Kevin Kofler wrote:
> Brian Pepple <bpepple <at> fedoraproject.org> writes:
> >http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans
> >http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections
>
> Ugh, developers _already_ struggle with filling in all the sections, which
> sometimes simply don't apply to the feature, how is even more bureaucracy going
> to help? Let me take a past feature as an example (for lack of ability to
> predict the future): try writing a complete detailed test plan for
> FeatureKDE4... And no, you don't have 3 years to write it and I don't think the
> wiki will scale to megabytes of text in a single feature page. ;-) And in
> addition to sections just not relevant to the specific feature, there's also
> the issue of developer time being wasted on bureaucracy, time which not all
> developers have: the FeatureKDE4 page ended up as complete as it now is because
> we spent lots of time on it, some feature pages are in a much worse state, and
> I don't think pressure like the above "process improvements" is going to help,
> because this isn't laziness, it's genuine lack of time.

Think about it this way: it means that there will be no features ready
for approval when the time comes. So as a side-effect it achieves the
"Reduce FESco overhead" goal...

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-08-2008, 01:35 AM
Josh Boyer
 
Default FESCo Meeting Summary for 2008-07-03

On Mon, 2008-07-07 at 19:27 -0400, Matthias Clasen wrote:
> On Mon, 2008-07-07 at 21:45 +0000, Kevin Kofler wrote:
> > Brian Pepple <bpepple <at> fedoraproject.org> writes:
> > >http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans
> > >http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections
> >
> > Ugh, developers _already_ struggle with filling in all the sections, which
> > sometimes simply don't apply to the feature, how is even more bureaucracy going
> > to help? Let me take a past feature as an example (for lack of ability to
> > predict the future): try writing a complete detailed test plan for
> > FeatureKDE4... And no, you don't have 3 years to write it and I don't think the
> > wiki will scale to megabytes of text in a single feature page. ;-) And in
> > addition to sections just not relevant to the specific feature, there's also
> > the issue of developer time being wasted on bureaucracy, time which not all
> > developers have: the FeatureKDE4 page ended up as complete as it now is because
> > we spent lots of time on it, some feature pages are in a much worse state, and
> > I don't think pressure like the above "process improvements" is going to help,
> > because this isn't laziness, it's genuine lack of time.
>
> Think about it this way: it means that there will be no features ready
> for approval when the time comes. So as a side-effect it achieves the
> "Reduce FESco overhead" goal...

While I realize you were making a sarcastic remark, I would like to
point out that we (FESCo) didn't even discuss that "goal" during the
meeting. John added that right before the meeting trying to be nice to
us and we didn't even think it worth discussing because of other points
brought up by the other goals and the fact that Features are decided
FESCo's _job_.

josh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-08-2008, 01:42 AM
Josh Boyer
 
Default FESCo Meeting Summary for 2008-07-03

On Mon, 2008-07-07 at 21:45 +0000, Kevin Kofler wrote:
> Brian Pepple <bpepple <at> fedoraproject.org> writes:
> >http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans
> >http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections
>
> Ugh, developers _already_ struggle with filling in all the sections, which
> sometimes simply don't apply to the feature, how is even more bureaucracy going
> to help? Let me take a past feature as an example (for lack of ability to

It will help FESCo decide if the Feature is a) worthwhile, b) even
testable at all, and c) provide us with some kind of QA plan so we
aren't touting a Feature that is totally broken.

> predict the future): try writing a complete detailed test plan for
> FeatureKDE4... And no, you don't have 3 years to write it and I don't think the
> wiki will scale to megabytes of text in a single feature page. ;-) And in

We aren't asking you to document the testcase in it's entirety, and
obviously some Features will be able to more clearly state their test
plans than others.

> addition to sections just not relevant to the specific feature, there's also
> the issue of developer time being wasted on bureaucracy, time which not all
> developers have: the FeatureKDE4 page ended up as complete as it now is because
> we spent lots of time on it, some feature pages are in a much worse state, and
> I don't think pressure like the above "process improvements" is going to help,
> because this isn't laziness, it's genuine lack of time.

KDE4 was (and still is) an exception to most of the Features we see due
to it's broad scope and large complexity. The fact that you documented
your Feature page as well as you did is a testament to you and your
SIG's dedication to see the Feature thrive in Fedora. If the some of
the other Feature owners did even 1/2 that, it would be an improvement.

Look at it this way, FESCo doesn't like to add overhead just for fun.
We really hate it to be honest. However, we aren't the developers of
these Features, and we have to have some way of understanding the
impacts of it, why it should be a Feature, and how we (the Fedora
project) are going to ensure it's not totally broken. If you have
better suggestions on how to do that, then please suggest them! This is
the best proposal we've seen to date and it contains the information in
a single place.

(And no, hounding people on IRC or via private/public email isn't really
an option.)

josh

--
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 10:57 AM.

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