Re: Fedora clean up process seems to be seriously broken...

[David Tardon]

This is just a collection of random thougths on some of the ideas you
presented in this thread.

> Nobody is putting burden on anyone other then the maintainers themselves.
>
> Either they do it directly to themselves ... or it's being
> done by other sloppy/non responsive/absent maintainers indirectly
> through the component they are supposed to maintain ...
> or through various policy's/processes we in place trying to deal with
> those.

and then later (the text in [] is inserted by me)

> But no the proposal [that forces all new packages to have "how to
> debug page"] made to FESCO/FPC winded up in *Recommendation*
> instead *Requirement* which automatically made that process and effort
> to be in vain since I knew that maintainers would not provide that
> information if they did not have to and guess what I turned out to be right.
> 
> Same thing goes for "how to test" since maintainers would have to
> provide us with the information what was the best way to test their
> component ( for the most part anyway ). Without that information process
> like proven testers is just a waist of time and unnecessary bureaucracy.
> ( just one of the issues why something like proven testers does not and
> will not work ).

You are contradicting yourself, i.e., you are putting burden on
maintainers by requiring them to supply some "how to debug/test"
information. Furthermore, you are trying to solve bureaucracy by more
bureaucracy.

IMHO proventesters' process is waste of time and unnecessary bureaucracy
no matter what "how to test" information exists or does not exist.

> But basically you winded up being stuck with them since you wanted to
> ship component A but to do so you required B), C) and D) but nobody
> is/wants maintain B),C) and D).
> 
> Nothing can actually be done here since that's the price one has to pay
> wanting to ship component A).

Lets suppose that component A is something that is either used by (1)
many other components (e.g., some relatively low-level java package) or
(2) some leaf package, but one that lots of people use (e.g.,
libreoffice). Now lets examine these cases one by one:

(1) Guess what is going to happen if the maintainer "unburdens" himself
of packages he only maintains as dependencies for "his" package (like
packages B, C, D from your example). Either _some other maintainer up
the stack_ without real interest in them steps in and takes them,
effectively leaving the situation as it was before; or we drop them,
together with A and everything that depends on A. Good! We got rid of a
lot of "poorly" maintained packages and got a much better maintained
distro! (E.g., who cares if we just dropped java? What do we need java
in Fedora for, anyway?)

(2) The same reasoning follows, only with the result that just one
package is dropped. E.g., if the libreoffice team decided to give up
maintenance of the jfreereport packages, nobody else took them and they
were dropped, we would be forced to drop libreoffice as well (actually,
we would just use the bundled jfreereport, Fedora policies be damned...)
I would really like to see you explaining in release notes how dropping
libreoffice increases "the overall quality of distribution".

> Not sure what you mean about distro integrity since arguably shipping
> few but well maintained components is better then shipping many poorly
> maintained or not maintained at all.

Arguably the foremost goal of the distribution is shipping useful
software. If we stop doing that because some unfortunate (right, lets
not call it "stupid") policy demands that we drop "poorly maintained"
(but still perfectly functional) packages, we may as well give up the
whole effort, because we are becoming yet another niche distro.

Just try to understand maintainers do not put software in Fedora for the
sake of it--they do it with the idea that it is going to be useful for
other people. If I look at a distribution and see that half of the
software I use is not there, I will not use that distribution, no matter
how "well maintained and tested" the rest is. It is as simple as that.

> You may consider this an sloppy I however do not as I see it the how to
> debug page for your component is necessary since without having spoon
> feeding information on how to do that the reporter will never be able to
> provide you with the information you want.
> 
> We simply can not improve reporting in general without having the
> necessary documentation on how to obtain that information and what
> minimal information the maintainer wants (  the how to debug pages ).

This is a fallacy. Even if such documentation existed, who says that an
average reporter would (1) read it and (2) act on it? It also assumes
that troubleshooting of _every single package_ can be reduced to a
couple of instructions and it does not take into account at all that in
considerable number of cases it is not clear which component is causing
the problem (is it the application? Or is it one of the libraries it
uses?)

I wil

systemd, disabling cryptsetup device

[Jan Vcelak]

Hi everyone!

Is there a way of forcing systemd not to mount an encrypted partition when 
booting the system? I have one encrypted partition (on LVM) on my laptop, which 
I do not want to have mounted automatically. I'm mounting it only when I need 
it with a simple script.

With F15, masking the cryptsetup@luks*.service file worked. (The password 
prompt appeared and disappeared in a second, which didn't mind.) But this no 
longer works with F16. So, is there a way? Is this behavior intended, or is it 
a regression?

my kernel options:  ro root=/dev/mapper/vg_nb-lv_root rd_LVM_LV=vg_nb/lv_root 
rd_NO_LUKS rd_NO_MD rd_NO_DM

Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora clean up process seems to be seriously broken...

[Michael Schwendt]

On Wed, 23 Nov 2011 08:18:11 -0600, RS (Richard) wrote:

> I didn't imply that there should be less documentation or guidelines,
> only that it's more than a person can "grok" at one time. 

That's too vague for me to understand it.

Some topics are covered by entire books, for example even several
commercial books about RPM exist in addition to the documentation that can
be read online. To stick to the example of RPM packaging, the Fedora Wiki
tries to sum up the basics already, in HOWTOs such as:

  https://fedoraproject.org/wiki/How_to_create_an_RPM_package

  https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package

One needs to start *somewhere*, also when starting to read a book.
How terse can it get while still being helpful and without neglecting to
comment on stuff that's really relevant to most packages?

There is no Fedora specific documentation that tries to serve as an
elementary course on C, C++, GCC, or GNU Autotools, for example. How many
manual pages, info files, and books can a person "grok at one time"? It
may be necessary to gain experience the learning-by-doing way and by learning
from others, who either know the guidelines in detail or who give
explanations beyond what's covered by the guidelines.

> My thoughts
> are that it would be better if there was some way to ease people into
> it, just as in school you don't go straight to Calculus or DE, but
> start with geometry and then algebra and you work your way up to the
> more complicated stuff, building your knowledge base as you go.

You sound as if you've found an area of Fedora you could try to improve.
That might be much more productive than trying to convince others of flaws
you've discovered. Whether you would work on new pages in the Wiki or do
Fedora IRC classroom sessions, I dunno.

I'd like to add that it's much more fun to work with potential
contributors, who ask questions and show interest, than those who sit and
wait somewhere without any questions/comments on the guidelines. The FPC
regularly spends time on improving the guidelines whenever there is
feedback on them.

The package review process and the packager sponsoring procedure is
supposed to be some hurdle. Potential contributors are expected to show
some level of perseverance, some sort of prove that they are willing to
become a Fedora contributor. If it were too easy to dump a package into
the distribution (and there really are some, who lump together a package
based on a src.rpm they've found somewhere, announcing that they want this
to be include in Fedora without being the ones to maintain it), I assume
we would have a lot more problems with packagers, who drop off silently as
soon as they receive a few bug reports or run into problems related to
their package(s).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora clean up process seems to be seriously broken...

[Michael Schwendt]

On Thu, 24 Nov 2011 11:49:00 +0100, I wrote:

> [...]
> some level of perseverance, some sort of prove that they are willing to
> [...]

s/prove/proof/

-- 
Not an attempt at fixing all embarrassing typos, however. ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Dropping the ownership model

[Stanislav Ochotnicky]

Excerpts from Kevin Kofler's message of Tue Nov 22 19:24:22 +0100 2011:
> Miloslav Trmač wrote:
> > I wouldn't want to get rid of the ownership model altogether, I think
> > there should be a specific person responsible for handling bug
> > reports/RFEs.  When a group is responsible to handle something not
> > really pleasant to do, often no single member of that group feels
> > personally responsible.
>
> All the core KDE packages are de facto SIG-maintained; no matter who the
> official primary maintainer of the particular package is, we all feel
> equally responsible for them. This works very well.

All (or most) code KDE packages come from the same source, have the
same build system, same quality standards etc. This is not really true
for most "package sets" a group of people might be interested in. They
will share some similarity (common macros, standard sub-packages etc.)
but vary greatly otherwise.

Since Java packages were already mentioned, we have hundreds of
them. There are sets of packages that are similar to KDE
(apache-commons-*), but most of java packages are coming from
different sources. Some upstreams bundle dependencies, some
don't etc.

That said we welcome comaintainers and I've never been shouted at for
using my provenpackager privileges to update spec to latest guidelines
or for fixing a bug. But even though I know our Maven build system in
and out, it's sometimes hard to predict failures caused by some
changes. A single mistake in package can result in big problems
(where even raising Epoch wouldn't help because build would fail).


So I'd modify the proposal a bit...loosen the requirements on
rawhide. If someone screws it up there, no problem. It will be found
soon enough even if the problem is somewhere deep down in the basic
dependencies.

--
Stanislav Ochotnicky 
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gdk-pixbuf being retired

[Petr Pisar]

On 2011-11-22, Kevin Fenzi  wrote:
> On Mon, 21 Nov 2011 18:40:14 -0600
> Bruno Wolff III  wrote:
>
>> I picked up gdk-pixbuf because freetennis supposedly depended on it
>> but actually doesn't. (Though freetennis if also FTBFS for another
>> reason so clearing the dependency isn't simple.) Though only thing
>> that really depends on it is xosd-xmms and I have checked with Kevin
>> about that and he will remove that subpackage or retire xosd.
>>
>> gdk-pixbuf is FTBFS because it won't build without rerunning some of
>> the autotools programs and does not build with the currently available
>> autotools versions available. There are a number of errors reported
>> that would need to get this building again and the effort doesn't seem
>> worth it.
>>
>> So I have now retired the package in rawhide (f17).
>
> To go along with this, I am retiring xosd. There are still a few things
> that use it or have xosd subpackages. If any of those folks want to
> take it over, they would need both it and gdk-pixbuf.=20
>
[...]
> xmms-xosd-0:2.2.14-14.fc15.x86_64

xmms-xosd is subpackage of xosd. xosd requires gdk-pixbuf-0 only because
of the XMMS plug-in.

Because I use xosd but XMMS, I'm taking xosd to continue it without XMMS
extension.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped

[Richard W.M. Jones]

On Wed, Nov 23, 2011 at 10:20:50AM -0500, Kaleb S. KEITHLEY wrote:
> On 11/23/2011 10:08 AM, Orion Poplawski wrote:
> > On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote:
> >>
> >> I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64
> >> and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...`
> >> respectively.
> >>
> >> I can also build using mock, both x86_64 and i386, with `mock -r
> >> epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...`
> >> respectively.
> >>
> >> In all the above cases I get all the expected RPMs and the build.log
> >> shows no errors.
> >>
> >> But when I do a `fedpkg build` or a `koji --scratch ...`  in the el6
> >> branch of my fedora-scm tree the builds fall down with an error
> >> compiling a y.tab.c file. Suffice it to say it builds for f16 and
> >> rawhide just fine using the exact same sources and spec file.
> >>
> >> Build logs aren't particularly helpful and since they succeed in mock
> >> and rpmbuild I can't debug the build issue locally. Obviously there's a
> >> compile error of the y.tab.c file, but I can't see why it doesn't work
> >> in koji when it does work everywhere else.
> >>
> >> Perhaps there's some extra fedpkg flag I should be using for epel builds?
> >
> > Perhaps try without parallel make?
> 
> Yes, that makes it work.

This might indicate a bug in the Makefile, so really that should be
fixed.  If you could point to the place in the source where it fails,
then we could take a look.

Parallel makes are desirable, particularly on modern multicore
processors where each core might be slow but you've got lots of them.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gdk-pixbuf being retired

[Petr Pisar]

On 2011-11-24, Petr Pisar  wrote:
>
> xmms-xosd is subpackage of xosd. xosd requires gdk-pixbuf-0 only because
> of the XMMS plug-in.
>
> Because I use xosd but XMMS, I'm taking xosd to continue it without XMMS
> extension.
>

xosd has been submitted for re-review
 per

 process.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped

[Paul Howarth]

On 11/24/2011 01:54 PM, Richard W.M. Jones wrote:
> On Wed, Nov 23, 2011 at 10:20:50AM -0500, Kaleb S. KEITHLEY wrote:
>> On 11/23/2011 10:08 AM, Orion Poplawski wrote:
>>> On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote:

 I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64
 and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...`
 respectively.

 I can also build using mock, both x86_64 and i386, with `mock -r
 epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...`
 respectively.

 In all the above cases I get all the expected RPMs and the build.log
 shows no errors.

 But when I do a `fedpkg build` or a `koji --scratch ...`  in the el6
 branch of my fedora-scm tree the builds fall down with an error
 compiling a y.tab.c file. Suffice it to say it builds for f16 and
 rawhide just fine using the exact same sources and spec file.

 Build logs aren't particularly helpful and since they succeed in mock
 and rpmbuild I can't debug the build issue locally. Obviously there's a
 compile error of the y.tab.c file, but I can't see why it doesn't work
 in koji when it does work everywhere else.

 Perhaps there's some extra fedpkg flag I should be using for epel builds?
>>>
>>> Perhaps try without parallel make?
>>
>> Yes, that makes it work.
>
> This might indicate a bug in the Makefile, so really that should be
> fixed.  If you could point to the place in the source where it fails,
> then we could take a look.
>
> Parallel makes are desirable, particularly on modern multicore
> processors where each core might be slow but you've got lots of them.

The Fedora buildsystem is particularly good at rooting out parallel 
build issues due to its very high parallelism, as I found out recently 
when it uncovered a long-standing build issue in pptp:

http://marc.info/?l=pptpclient-devel&m=132102054518031

Paul.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped

[Richard W.M. Jones]

On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
> http://marc.info/?l=pptpclient-devel&m=132102054518031

This is indeed rather unexpected behaviour of make!

BTW I think your patch is incomplete, since it will create an
incomplete config.h if the disk runs out of space.  I think this would
be better, and should also avoid the parallel make problem:

config.h:
echo "/* text added by Makefile target config.h */" > $@-t
echo "#define PPTP_LINUX_VERSION \"$(VERSION)$(RELEASE)\"" >> $@-t
echo "#define PPPD_BINARY \"$(PPPD)\"" >> $@-t
echo "#define IP_BINARY \"$(IP)\"" >> $@-t
mv $@-t $@

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped

[Jim Meyering]

Richard W.M. Jones wrote:
> On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
>> http://marc.info/?l=pptpclient-devel&m=132102054518031
>
> This is indeed rather unexpected behaviour of make!
>
> BTW I think your patch is incomplete, since it will create an
> incomplete config.h if the disk runs out of space.  I think this would
> be better, and should also avoid the parallel make problem:
>
> config.h:
>   echo "/* text added by Makefile target config.h */" > $@-t
>   echo "#define PPTP_LINUX_VERSION \"$(VERSION)$(RELEASE)\"" >> $@-t
>   echo "#define PPPD_BINARY \"$(PPPD)\"" >> $@-t
>   echo "#define IP_BINARY \"$(IP)\"" >> $@-t
>   mv $@-t $@

Yes, that is better and does solve the problem.

Here's a good rule I've been following since I was first burned by this:
"never redirect directly to a Makefile target". (where "target" means $@
or any literal that is equivalent).  That means redirect output to a
temporary file like Rich did above, and only when that process is known
to have succeeded do you rename the temporary file to $@.

However, I would volunteer some additional suggestions:

  - use a {...} group (cheaper than a (...) subshell) so we redirect only once;
that reduces the duplication of the "$@-t", and eliminates the dichotomy
of the initial "> $@-t", while all subsequent ones are ">> $@-t".

  - use outer single quotes so you don't have to backslash-escape the
inner double quote chars.  less syntax is more maintainable.

  - make the file read-only, so it is clearer that it is generated,
and thus harder to change accidentally.  The only down-side to
this part is that you then have to be careful to remove any
preexisting $@ or $@-t, since redirecting onto a read-only file
will often fail.

config.h:
rm -f $@ $@-t;  \
{   \
  echo '/* text added by Makefile target config.h */';  \
  echo '#define PPTP_LINUX_VERSION "$(VERSION)$(RELEASE)"'; \
  echo '#define PPPD_BINARY "$(PPPD)"'; \
  echo '#define IP_BINARY "$(IP)"'; \
} > $@-t && chmod a-w $@-t && mv $@-t $@
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped

[Jim Meyering]

Kaleb S. KEITHLEY wrote:
...
>>> Perhaps there's some extra fedpkg flag I should be using for epel builds?
>>
>> Perhaps try without parallel make?
>
> Yes, that makes it work.
>
> Thanks for the tip.

When running make from the command line, I always use -j$N, for 1 < N.
But of course, I rarely type the -j option.
Not only do builds complete more quickly, but doing that
helps flush out problems like yours.

I run this shell code to create an alias:

  _make_init()
  {
local n=$(nproc 2>/dev/null || getconf _NPROCESSORS_ONLN 2>/dev/null)
test "$n" -gt 0 \
  || n=$(grep -c '^processor  :' /proc/cpuinfo 2>/dev/null)
case $n in 0) n=1;; esac
local make_j=$((2 * $n + 1))
# Create an alias for "make" that uses -j$N, where $N is determined
# once at shell start-up.
alias make="make -j$make_j"
  }
  _make_init
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped

[Jim Meyering]

Richard W.M. Jones wrote:
> On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
>> http://marc.info/?l=pptpclient-devel&m=132102054518031
>
> This is indeed rather unexpected behaviour of make!

Actually it should not be unexpected.
Whenever you update a target non-atomically that can happen.

The moment the first non-atomic write affects the target,
any parallel make job that is then inspecting that file's "mtime"
(date of last modification) will think that it is "up to date"
and consider it ready to be used.  That is why the recommended
approach is to write only to a temporary (as you did below)
and only update atomically via mv's rename.

> BTW I think your patch is incomplete, since it will create an
> incomplete config.h if the disk runs out of space.  I think this would
> be better, and should also avoid the parallel make problem:
>
> config.h:
>   echo "/* text added by Makefile target config.h */" > $@-t
>   echo "#define PPTP_LINUX_VERSION \"$(VERSION)$(RELEASE)\"" >> $@-t
>   echo "#define PPPD_BINARY \"$(PPPD)\"" >> $@-t
>   echo "#define IP_BINARY \"$(IP)\"" >> $@-t
>   mv $@-t $@
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Dropping the ownership model

[Michael Scherer]

Le mardi 22 novembre 2011 à 13:20 -0500, Aleksandar Kurtakov a écrit :
> As much as we have disagreed on the previous topic we might have similar 
> thoughts here :).
> 
> - Original Message -
> > From: "Jóhann B. Guðmundsson" 
> > To: "Development discussions related to Fedora" 
> > 
> > Sent: Tuesday, November 22, 2011 7:51:31 PM
> > Subject: Dropping the ownership model
> > 
> > What do people see as pros and cons continuing to use the current
> > package ownership model?
> > 
> > Would it be practical to dropping it altogether which in essence
> > would
> > make every contributor an "proven packager"?
> 
> Well, everyone becoming a proven packager is going too far from the 
> beginning. 
> Though I have to say that this approach worked quite good in Mandriva in the 
> past.
> I still remember misc telling me "please don't break too much" . For the few 
> years I maintained packages there 
> I haven't seen a single case of someone abusing his powers. 

Things may have changed a little nowadays :) 

Mandriva, who use a system similar to what was proposed by Johann, face
some issues ( lots of package not officially maintained, so the and that
caused some problem ), and recently faced some friction with some
contributors. 

On the other hand, this helped a lot to be able to maintain the
distribution with a rather lower number of people. It should be kept in
mind that security support on stable is done by a dedicated (often
overworked) team, for a supported subset of rpm only, and done by
community for the rest ( and that was rather messy ). 

For Mageia, we ( or at least I ) try to see if a mix between the two
could be used :

- all packages ( modulo some exceptions ) can be modified by anybody in
the proper group ( packager ). People need to be trained before pushing
packages. 

- at least 1 person should responsible of each package ( ie, get bug
report, do security update, has the last word in case of issue with
others packagers, unless conflict is escalated to $governance_bodies ).
But due to various organisational issue ( like having created packages
before having a working packager database ), there is still lots of
unowned packages.

- changes to a package are notified to the maintainer ( and others ).
( not done currently, but on the TODO list since a long time ). Inspired
by the kde svn notification system.

And we have a rather conservative approach regarding version upgrade,
especially during freeze and on stable releases, so the problem of
"someone upgraded libfoo and broke some stuff" is lower ( not inexistant
but at least, it only touch the devel version, which is less risky than
rawhide according to most people, and so more used ). 

I have also noted people do not like the idea of dropping unmaintained
packages, but such is human nature. 

Some of Mageia packagers have asked for group maintainership, similar to
the SIG-maintainer proposal, but for the same reason highlighted in the
thread, i fear this would dilute responsibility. 

Something worth keeping in mind is to separate the actual commit/submit
rights from any type of notification. IE, I am quite sure that some
people would be happy to get notification of bugs and changes on some
packages, without being co-maintainer. This would permit to find
co-maintainers more easily IMHO, and surely foster cooperation between
various distributions and with upstream. This would also help by
engaging testers, etc.

-- 
Michael Scherer

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: A Glorious Vision of Our Shared Update Feedback Future (bodhi, karma, and proventesters, oh my)

[David Tardon]

On Tue, Nov 22, 2011 at 02:03:16PM -0800, Adam Williamson wrote:
> On Tue, 2011-11-22 at 21:58 +, "Jóhann B. Guðmundsson" wrote:
> 
> > With the above information what benefits/value will we have by having 
> > proven tester over fas tester hitting the panic button
> > ( since no addinal testing is being performed by the proven tester over 
> > fas-tester thus it makes no difference if fas-tester or proven tester 
> > hits the panic button)
> 
> The proposal is to treat a PT hitting the panic button even more
> dramatically than a registered user hitting it, the idea being that PTs
> should be somewhat better informed and hence less likely to trigger it
> falsely, and that we have the mechanism to withdraw PT privileges, so if
> a PT does trigger, say, two false alarms, we can simply make them not a
> PT any more. It's much more of a drastic step to revoke someone's FAS
> account.

I'm a bit concerned about the fact that we seem to put an equality sign
between "proventester" and "knowledgeable user of the package in
question". IOW, how a membership in some group makes one know what is
needed to test a random package? I could argue that if some random FAS
user tests a package, he does it because he actually uses it, whereas a
"proventester" may be doing it just from a sense of obligation ("I
should be testing updates!"). Therefore the normal user's word should
carry more weight...

And no, the existence of "how to test" document does not change the
situation. If a "proventester" needs it to be able to test a package (as
opposed to "use it as a checklist so he does not forget anything
important"), then he is especially not suited to make an authoritative
decision about the state of the package. Because in that case he is just
a "trained monkey" and cannot be distinguished from a randomly picked
FAS user.

D.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel