On Wed, 2008-07-09 at 20:12 +0200, Thorsten Leemhuis wrote:
> On 09.07.2008 12:51, Panu Matilainen wrote:
> > At long last, we are about to get a brand new RPM version (alpha snapshot
> > at the moment) into rawhide. The list of changes from 4.4.2.x is massive
> > and a full summary needs a separate posting (will follow as time permits),
> > this is just a heads-up of immediate consequences for Fedora packagers and
> > rawhide consumers:
>
> Sounds great, thanks Panu and others! Much appreciated and looked
> forward to.
>
> 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.

Good point.

> So is the most of the Feature process (and especially FESCo's approval)
> useless overhead?

I don't think so. I think the rpm example illustrates the weakest point
of the process, and it should be worked on rather than be declared as
useless.

It does happen to be my biggest pet peeve of the Feature process,
because this will now become a "Feature" that gets defacto approval
simply because it's already in. I HATE doing that, because as you said
it is largely a waste of time. So we need to be a bit more proactive
about it.

I'll argue that not every package upgrade is worth a Feature
designation. But the major ones should be. Firefox 3 had one. I
believe OpenOffice.org should have one. For a major rpm upgrade, there
should be one as well.

josh

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

On Wed, Jul 9, 2008 at 10:26 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> I'll argue that not every package upgrade is worth a Feature
> designation. But the major ones should be. Firefox 3 had one. I
> believe OpenOffice.org should have one. For a major rpm upgrade, there
> should be one as well.

Distill that feeling into a generally applicable statement that
package maintainers can use as a conditional test as to whether or not
they should file a feature.

For example... the python-matplotlib that I just introduced into
rawhide.. it has enhancements, and some internal api changes. Does it
matter enough as a package to be a Fedora Feature?

If I can get a new gdl built with the python module support
enable..will that matter?

I need a bright line test that makes sense that limits how much of my
individual judgement has to be used for the packages that I maintain.
I need a checklist or a scorecard....I need a Cosmo quiz.

And its completely okay if the test/checklist/scorecard that we think
is best can be fully created yet. For example.. if we feel that a
packages "popularity" is important to rank something as a feature,
then we put that on the checklist and we then go out and build
whatever popularity metric is necessary to support that part of the
checklist.

-jef"is definitely not in favor of any popularity metric"spaleta

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

On Wed, 09 Jul 2008 20:12:58 +0200, you wrote:

>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 think the most issue of a new RPM release is the fact, that
other package like yum may interfere from it, and that they may
got issue during the installation/upgrade process of Fedora, so a
Feature process may be require from my point of view.

At last we new a failback or blocking strategy, if there should
be any severe issue which block the release fo F-10.

Best Regards:

Jochen Schmitt

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

On Wed, 2008-07-09 at 11:26 -0800, Jeff Spaleta wrote:
> On Wed, Jul 9, 2008 at 10:26 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> > I'll argue that not every package upgrade is worth a Feature
> > designation. But the major ones should be. Firefox 3 had one. I
> > believe OpenOffice.org should have one. For a major rpm upgrade, there
> > should be one as well.
>
> Distill that feeling into a generally applicable statement that
> package maintainers can use as a conditional test as to whether or not
> they should file a feature.

Simplistic start of a checklist:

1) Is your package included in the default install of one of the main
spins?

2) Is your package _the_ default application of it's type?

3) Is your package involved in the building of the entire distro? (E.g.
rpm, gcc, glibc)

4) Are there a large number of packages that depend on your package that
will be effected by an upgrade/change/etc ?

5) Are you trying to promote this package as a Feature for publicity
reasons?

6) Does your package enable something that is highly end-user visible
(e.g. magically working wireless, push button pony making)

If yes to any of the above, please create a Feature page. If no, and
or/you are still unsure, ask one of your FESCo representatives and they
will guide you.

josh

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

On Wed, 2008-07-09 at 23:34 +0300, Panu Matilainen wrote:
>
> The simple-minded bass-player in me has just one practical question: what
> do we do about it? Sure we can go through the feature process, it'll just
> probably mean the new rpm will miss F10 alpha. Whether that's a good thing
> or not might depend on if you're in rel-eng or not

If we can dedicate a couple helpers to you, I bet we could get a feature
page written up quickly, and I bet we could get FESCo approval in good
faith on getting a suitable feature page up, after the package is built.

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2008-07-09 at 23:34 +0300, Panu Matilainen wrote:
> On Wed, 9 Jul 2008, Thorsten Leemhuis wrote:
> > 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.
>
> One reason for missing out on the feature process is probably that I've
> found it somehow alien thing to begin with - I don't consider myself
> working on a "Fedora feature", I'm "working on rpm.org upstream" to get a
> much-needed update to the aging RPM version we have been living with for
> ages. Mind you, this is not an excuse for missing out on distro policies.
> The line between a "feature" and a "non-feature" is extremely obscure
> really, and I think the point of "if you're unsure, ask" has not been made
> sufficiently clear. Until perhaps now

Maybe it also helps to think of the Fedora feature process as leveraging
what Fedora can provide for an upstream community. Two things that come
to mind immediately are QA/testing and widespread publicizing of the
feature.

--
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

On Wed, Jul 9, 2008 at 1:12 PM, Thorsten Leemhuis <fedora@leemhuis.info> wrote:
> 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.
>
> 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.
>
> 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.

This is my understanding:

The Feature process was implemented to be a conduit for the
Engineering side of Fedora to collaborate with the Marketing side of
Fedora, to allow the Marketing people to build up pre-release hype for
new features without having to second-guess us notoriously busy, and
quiet, engineering types. It allows the Marketing people to keep tabs
on engineering activities and have reasonable certainty as to the
status of the feature, specifically whether or not it is going to be
finished in time for the final release.

It is a stack of bureaucracy in which us Engineering people
voluntarily participate, in order to improve our PR activities for the
greater good of the project.

"voluntary" being the key word here. No one should be forced to
participate. However not going through the feature process discourages
the Marketing people from advertising your work in pre-release hype.

Am I wrong?

Honestly, though the new RPM affects us package monkeys quite a bit, I
don't think it means much to the majority of general Fedora users. It
*shouldn't* mean anything. RPM should be the machinery that, when its
doing its job right, quietly goes on doing its job without anyone but
us package monkeys noticing.

Though I do foresee *cough* certain people *cough* complaining about
how their spec they've used unchanged since RHL 6.2 no longer builds,
and accuses us of "breaking things" and "actively sabotaging" RPM...
So this should probably get prominent notice in the release notes, at
least.

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

On Wed, Jul 09, 2008 at 03:43:44PM -0400, Josh Boyer wrote:
>
> 5) Are you trying to promote this package as a Feature for publicity
> reasons?

I think that only this one should be relevant. That is is the packager
willing to communicate the change.

--
Pat

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

On Thu, 2008-07-10 at 08:09 +0200, Patrice Dumas wrote:
> On Wed, Jul 09, 2008 at 03:43:44PM -0400, Josh Boyer wrote:
> >
> > 5) Are you trying to promote this package as a Feature for publicity
> > reasons?
>
> I think that only this one should be relevant. That is is the packager
> willing to communicate the change.

I don't. Features aren't only about publicity. If they are large
enough and could potentially break things, FESCo/QA/RelEng want to see
test plans and fallback options.

josh

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

On Wed, 2008-07-09 at 20:41 -0500, Callum Lerwick wrote:
> Am I wrong?

Yes. As previously stated the feature pages are way more than just
marketing fluff. Features have very real schedule impact, just consider
this time around, RPM with a bunch of new features, and a new gcc coming
at some point soon. Usually we want to rebuild for both of those.
Without some high level coordination, how do we schedule so that we
rebuild once for all of the right reasons instead of multiple times
individually?

How can releng/qa properly schedule timelines for testing and what
should be tested based on the changes? How do we know when we should
slip for specific features that are close but just haven't quite made it
yet?

The feature process allows greater visibility and coordination across
the entire distribution, which is quite large. Fedora is a far cry from
the RHL days when most everybody working on it was in the same room, and
the few that weren't were easy to find on IRC. We're vastly different
and larger and need these communication/coordination efforts to continue
to be successful.

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list