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 03-09-2010, 12:51 PM
Karel Zak
 
Default Proposed udpates policy change

On Tue, Mar 09, 2010 at 02:10:58PM +0100, Jaroslav Reznik wrote:
> On Tuesday 09 March 2010 13:55:53 Seth Vidal wrote:
> > On Tue, 9 Mar 2010, Karel Zak wrote:
> > > Always when I see that someone is trying to introduce a new rule I
> > > have to ask myself ... why so large project like kernel is able to
> > > successfully exist for 20 years without a huge collection of rules?
> >
> > the kernel has one rule which ends up working very well. The kernel has
> > the "its Linus' (and a few other people's) way or the highway".
> >
> > Now, if you'd like to see fedora adopt that rule, I'd be curious to see
> > the results.

It's not (only) about Linus. It's about working environment and
strong focus on technical things.

Please, read:
http://www.kernel.org/doc/Documentation/ManagementStyle

> Yes, we don't have Linus here ;-) But usually I like his decisions - mostly
> strongly technical ones based on arguments = less politics.

Yes, less politics.

Karel

--
Karel Zak <kzak@redhat.com>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 12:56 PM
Matthew Garrett
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 06:00:20PM -0800, Chris Weyl wrote:

> Hmm. So. I have a package, perl-Moose, that has 4,667 tests run at
> build time. It depends on perl-Class-MOP, which has 2,225 tests, and
> it in turn depends on perl, which has 234,776 tests run at build. On
> a future note, we're working on setting up smoke testing, so when we,
> say, rebuild perl-Class-MOP we also run perl-Moose's tests.
>
> If I rebuild perl-Moose, or really, any of these packages, what sort
> of manual testing would you suggest we require before pushing the
> update?

Getting it onto users' machines. Testing that a library behaves as
documented isn't the problem - the risk is that there's consumers of
that library that depend on undefined and (thus) untested behaviour.
Making sure that some people who actually use this package install the
update reduces the risk that that happens.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 01:11 PM
Michael Schwendt
 
Default Proposed udpates policy change

On Tue, 9 Mar 2010 14:20:20 +0100, Mathieu wrote:

> I maintain some niche packages that almost no one uses/no one would
> provide karma for. But if I'm asked for a bugfix, and I do it, I want
> the people requesting it to tell me that it indeed fixes the issue and
> doesn't break anything else.

Hard to comment on as the scenario is too vague. The bugfix may be
trivial. The testing may be difficult. The added responsibility
requirements ("doesn't break anything else") are scary. The level
of participation the package maintainer asks for may be considered
too much by the user. The user may have moved on already. Do you want
to wait for the next user to find the same flaw?

> Why would I bother if they don't care?

Because other users judge about "your" broken product without contacting
you. That may be ordinary users, who build and spread an opinion about
Fedora's quality. Or more advanced users, who would build from source
tarball themselves and tell their friends and contacts that it works while
Fedora is broken. Or article writers, who review the distribution and may
try "some niche packages", too. The bug report from _one_ user may be the
most you get. Be thankful that somebody has taken the time to contact you.
Once you've been informed about the problem, the user expects you to take
appropriate action. Or else he would not remain a user, but would join and
become a co-maintainer or take over the package. You are the one to offer
something (on top of what upstream offers). Hence users believe that you
have bigger interest than themselves in fixing things.

It may be false expectations from users towards package maintainers,
but it's reality.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 01:12 PM
Seth Vidal
 
Default Proposed udpates policy change

On Tue, 9 Mar 2010, Karel Zak wrote:

> It's not (only) about Linus. It's about working environment and
> strong focus on technical things.
>
> Please, read:
> http://www.kernel.org/doc/Documentation/ManagementStyle
>
>> Yes, we don't have Linus here ;-) But usually I like his decisions - mostly
>> strongly technical ones based on arguments = less politics.
>
> Yes, less politics.
>

Less politics? Seriously?

man that's funny.

-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 01:26 PM
Dominik 'Rathann' Mierzejewski
 
Default Proposed udpates policy change

On Monday, 08 March 2010 at 22:59, Matthew Garrett wrote:
[...]
> Proposal
> --------
>
> The ability for maintainers to flag an update directly into the updates
> repository will be disabled. Before being added to updates, the package
> must receive a net karma of +3 in Bodhi.

-1 to this. I've packaged a number of things that I know just one user of.
I have no idea how many people actually use my packages or how to reach
them. Therefore it will most likely be impossible for me to get +3 on each
update and they'll never get out of testing. Do you really want this?

If this gets passed I'll probably orphan most of my packages (i.e. the ones
that have very little users). There's no point in maintaining them in Fedora
under this bureaucracy.

Regards,
R.

--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 01:56 PM
Alexander Kahl
 
Default Proposed udpates policy change

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/2010 10:59 PM, Matthew Garrett wrote:
> The ability for maintainers to flag an update directly into the updates
> repository will be disabled. Before being added to updates, the package
> must receive a net karma of +3 in Bodhi.

- -1, I would have to orphan most of my packages and give up my current
plans of founding a Common Lisp SIG as it will die suffering the
chicken-and-egg problem if this gets approval.
I'd rather fork Fedora than accept this without massive modification
(see my first post in this thread).

- --
Alexander Kahl
GNU/Linux Software Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuWYYEACgkQVTRddCFHw12RvQCeM5P2LRGw8V 6GazOn/3HU8pky
z1gAoKbM+V0VDXdK5MLcHj/298D7+1KW
=/bwH
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 02:26 PM
Toshio Kuratomi
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 11:41:44PM -0500, Jon Masters wrote:
>
> I believe that this is possibly too limited. Aside from the obvious
> abuse potential (which will always exist no matter what happens) -
> obviously someone could just hate the process and decide to have a
> couple of others sign off on everything no matter what - I think it
> should be necessary to have a cooling off period between pushing an
> update, it being voted on, and it going out live. It doesn't have to be
> weeks, but it should be long enough for the person who actually reported
> some bug to test that it is fixed and for others who aren't able to
> devote time every day to see the update. I suggest 3-5 days.
>
Note -- in the policy as written, there's no possibility of abuse because
there's no definition of what karma +1/-1 means.

In a different thread someone asked whether we wanted people to simply +1/-1
if the update installed.

In another thread, adamw said that QA's bar for acceptance is very low (he
had some examples but I'd rather he speak up than I go try to find it in the
mailing list archives :-).

This needs to be rectified as well.
-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 02:27 PM
Tomas Mraz
 
Default Proposed udpates policy change

On Mon, 2010-03-08 at 21:59 +0000, Matthew Garrett wrote:
> This is the policy that I expect to be discussed during the Fesco
> meeting tomorrow. This is entirely orthogonal to the ongoing discussions
> regarding whether updates in stable releases should be expected to
> provide features or purely bugfixes, and I don't see any conflict in
> introducing it before those discussions have concluded.
>
> Introduction
> ------------
>
> We assume the following axioms:
>
> 1) Updates to stable that result in any reduction of functionality to
> the user are unacceptable.
>
> 2) It is impossible to ensure that functionality will not be reduced
> without sufficient testing.
>
> 3) Sufficient testing of software inherently requires manual
> intervention by more than one individual.
>
> Proposal
> --------
>
> The ability for maintainers to flag an update directly into the updates
> repository will be disabled. Before being added to updates, the package
> must receive a net karma of +3 in Bodhi.

I am strongly against this proposal if it is enforced on all the
packages as a whole. It might be acceptable for critical path packages
however low profile packages which are not installed on most of the
systems (and we have huge number of such packages now in Fedora) will
not get the testing no matter what magic you will cast on the users to
attract them to testing.

A reasonable compromise might be to allow the manual push to stable
after a week or so of the package living in the testing repository.

Somehow speeding up the process of getting the package to the hands of
users once it is entered into bodhi would be also appreciable.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 02:42 PM
Toshio Kuratomi
 
Default Proposed udpates policy change

On Tue, Mar 09, 2010 at 09:52:28AM +0100, Dan Horák wrote:
> Matthew Garrett p*še v Po 08. 03. 2010 v 21:59 +0000:
> > This is the policy that I expect to be discussed during the Fesco
> > meeting tomorrow. This is entirely orthogonal to the ongoing discussions
> > regarding whether updates in stable releases should be expected to
> > provide features or purely bugfixes, and I don't see any conflict in
> > introducing it before those discussions have concluded.
> >
> > Introduction
> > ------------
> >
> > We assume the following axioms:
>
> I think first should come the answer on "what problem is this proposal
> trying to solve?". Is it the plain number of updates? Is it the quality
> of updates? What updates failed?
>
AFAICS, it's to prevent regressions from creeping into the updates repo
unnoticed. However, it's not clear what the problematic regression::wanted
bugfix ratio is.

Plain number of updates would probably be cut down by this proposal but
policy that addresses that directly is not present in the current document
-- that's been talked about on this list in other threads though.


-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 02:47 PM
Lennart Poettering
 
Default Proposed udpates policy change

On Mon, 08.03.10 21:59, Matthew Garrett (mjg59@srcf.ucam.org) wrote:

> The ability for maintainers to flag an update directly into the updates
> repository will be disabled. Before being added to updates, the package
> must receive a net karma of +3 in Bodhi.

Two questions:

How do you plan to convince people to actually test packages? My
understanding right now is that folks who end up testing packages do so
exclusively because they themselves ran into the bug that is being
fixed. And as soon as that itch they are scratching is fixed, they
seldomly report back about this. (At least that is what I am
experiencing. In quite a few cases I know that people happily took
packages from bodhi but never reported back)

Making the user Karma logic the *only* path into the stable distribution
hence makes the distro depend on feedback by our users. And I
wonder if we really want to depend on that.

And secondly: trhere are many bugs that are only triggered in very
particular use cases or on very particular hardware. Nonetheless they
are bugs that are worth to be fixed. For those it is going to be hard to
get updates accepted simply because the number of people who could and
want to test this is minimal. (And I know what I am talking of, having
to deal with PA compatibility with a vast number of different audio
hardware and drivers).

All in all, I think the Karma logic is a good tool to speed up things,
it is not useful as the *only* path into the stable distribution.

Unless of course we create some kind of body whose sole job is to test
and provide karma to updates that are not otherwise tested by the
users. And which hence can be blamed if packages stay stuck in bodhi.

Because right now there is a substantial number of updates I push that
stay stuck in bodhi for really long times because not enough people
bother... And if in the future those packages will stay there forever
because I cannot push them myself than I'd be royally annoyed.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 03:56 AM.

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