Re: critpath approval process seems rather broken

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/10/2011 01:23 PM, Sven Lankes wrote:
> On Sun, Apr 10, 2011 at 12:45:56PM -0400, Doug Ledford wrote:
> 
>> And here we are, about to go down the same road again.  I have an update
>> in updates-testing, it's getting no love, and the package that's in the
>> release is *known broken*.  It has not been updated for systemd to begin
>> with.  Nor for tmpfs /var/run.  And just like last time, I put out a
>> call for testers on this mailing list.
> 
> I had a closer look at the raid setup on my f15-box and as the raid was
> up as expected and poking at the raid with mdadm didn't turn up any
> issues, I've given it positive karma which has made it "Critpath
> approved".

Thanks for that.  I hope you read my other emails to Adam about the
testing of mdadm.  My point of those being that there is more to mdadm
than *just* bringing the raid arrays up (although that is, of course,
the biggest thing).  The fact that monitoring is down on the previous
version but ok on the current version is a big deal.  Monitoring is
almost as important in the real world as it is the difference between an
array going degraded and you knowing or you doing nothing until it
finally dies altogether.

> I mostly agree that Fedora as a whole has gone too far in the
> restrictions that are put in front of packagers to get updates pushed
> out to the distribution (and I'm not even maintaining any critpath
> packages). 
> 
> Back when this all started I felt that the promise was that "we'll put
> all this in place now and once AutoQA is ready, it'll all become much
> easier for everyone".
> 
> And while AutoQA seems to have come a long way in the last 8 months or
> so it's still not ready/solid/... enough to be used to base automatic
> decisions on (I'm not complaining - just stating facts) - so I'm still
> hopeful that the thumbscrews can be loosened somewhat.

When I was in 9th grade here in the US, I participated in the National
History Day competition.  You had to make a individual project, or group
project, or several other classes of entry.  I always did individual
project (this was my third year competing).  And each year the theme for
the competition was set early on and you had to be able to create a
project that embodied that theme.  This years theme was Rights versus
Responsibilities.  My project was about a saloon in the town that I grew
up in.  Back in the 1800's, the town I grew up in was this booming
mining town (lead, zinc, and galena).  And, of course, this was the
"wild west" days back in the US.  The streets were all dirt, people had
gun fights to settle differences, and the saloon was the major center of
social activity.  This particular saloon had a bar and restaurant on the
first floor, a casino on the second floor, and a brothel on the third
floor.  It was a rough and tumble place with little in the way of order
or law or discipline.  Then along comes the 1920's in the US.  That's
the era of prohibition.  Alcohol was illegal, and it nearly killed this
saloon entirely.  Not to mention the local officials cracked down on the
other unsavory aspect of the place.  Then in the 1930's, prohibition was
repealed and people had the right to drink again.  They tried to revive
the saloon, only to find that people weren't so willing to accept the
free and loose nature that the original saloon had, and it never really
recovered.  My project made it all the way to nationals, and I was asked
to defend it in front of a panel of judges and defend how it applied to
the theme.  I responded to their inquiries with the belief that the
House of Lords in Joplin, Missouri represented the three stages that
society often hits in the process of establishing a balance between
rights and responsibilities.  At some point in time, the rights will far
outweigh the responsibilities.  People will be free to do as they please
with no consequences for their actions.  Then, usually as a direct
result of abuses of those rights, society will crack down and take those
rights away.  Usually imposing entirely overly restrictive consequences
on people in order to curb the abuse.  Then, over time, society will
come to realize they might have over reacted and will curb the
consequences and bring the rights of the individual back in line with
their responsibilities.  My project then was about these three stages
and what they meant to this one establishment.  I took 8th place at
nationals that year (a classmate of mine placed in the top 3 with a
project about Harriet Tubman, but the fact that a little town with a
population of only 40,000 took two positions of the top 8 at nationals
that year is a story about our teacher, Marla Marantz).

The point of this long, rambling story that you couldn't care less about
is that I get the impression that Fedora is in stage 2 right now.  We
saw abuses by maintainers in the past, and we responded with draconian
rules that tied their hands, but in the process have ignored the fact
that the rules were too restrictive and didn't take various other
situations into account.  Now we are waiting for the pendulum to swing a
little more back to the middle of a balance between the freedom we used
to have and some accountability for our actions.  That's all fine and
dandy, I'm just saying we need to quit wasting time in phase two and
move on to phase three.

>> But like I tried to explain after F14's fiasco, most people simply don't
>> have the knowledge and hardware to truly test mdadm.
> 
> It doesn't render my system unbootable, my raid still comes up after the
> update and casual mdadm calls don't turn up anything suspicious. That is
> all what I have tested and I don't feel that it's 'not enough'. The
> requirements on testing updates aren't very high - there just aren't
> enough testers (also many are testing not-yet-released versions in a vm
> and those are most likely not set up with a raid array ...).
> 
>> Well, I'm heading out of town for two weeks and will be away from net
>> connectivity.  This release's mdadm is what it is and it ain't getting
>> any better.
> 
> Looking at mdadm I notice two things:
> 
>  1. The package doesn't have a single co-maintainer. Having two or more 
>       people work on it would make "I'll be gone for two weeks" a non-
>       issue. There must be others interested and knowledgeable in the 
>       area that could serve as a backup?

If there were any interested parties I'm open.  Keep in mind that when I
was asked about the CVS access controls in the past, I opened mdadm up
to proven packagers.  Now, I know that isn't the same terminology used
today, but the idea is the same.  I specifically told them to set the
access controls so that good packagers could make changes and I'm not
the sort of fascist maintainer that will throw a fit if someone else
does something.  I will, if I deem a change bad, back it out and do
something different (or list me reasons why it was bad and do nothing),
but that's it.

>  2. You're working on it in bursts - mostly a few weeks before the
>       release. Submitting updates (especially rawhide-updates) more
>       often would also make things easier right before the release.

I maintain lots of packages, both in rhel and fedora, and I work based
upon release schedules.  The next thing to be released gets my
attention.  And sometimes not even that if I'm busy solving customer
focused problems at the moment :-(

-- 
Doug Ledford <dledford@xxxxxxxxxx>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband

Attachment: signature.asc
Description: OpenPGP digital signature

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux