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

 
 
LinkBack Thread Tools
 
Old 01-14-2008, 02:55 PM
Jesse Keating
 
Default "Action Items" From FUDCon?

On Mon, 14 Jan 2008 09:26:40 -0600
"Jeffrey Ollie" <jeff@ocjtech.us> wrote:

> I think that the least disruptive option is to enhance the tag
> checking script to prevent moving or deleting CVS tags that have been
> submitted to Koji for building. It's not a perfect solution because
> CVS provides very weak guarantees of data integrity/consistency but it
> may be "good enough".

Except that you can just call cvs itself to do the tag manipulation,
and that I don't think can be prevented.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-14-2008, 03:02 PM
"Jeffrey Ollie"
 
Default "Action Items" From FUDCon?

On 1/14/08, Mike McGrath <mmcgrath@redhat.com> wrote:
>
> No one ever really stood up and said "Here's my vision for what I think
> the next VCS should be" and stood with it (through the fire and flames
> that will come to anyone who does that).

I think that part of this is that no matter which VCS gets proposed
there's a certain percentage of the population that screams bloody
murder because either or both of these conditions are true:

1) It's not their pet VCS.
2) It's different from what the packaging community is used to.

It's definitely hard to get the motivation to withstand the religious debates...

Lennert Buytenhek has done a lot of work to build a solution using
Git, so if it's decided to go that route we've got a leg up.

> We had some people get into
> some very good discussions but unfortunately I think $DAYJOB is in the
> way.
>
> If someone is interested, here's the page, start putting meetings
> together. Until that time I think we're stuck with CVS.

Yeah, I think that's the rub here. The people who get paid to work on
Fedora are busy enough with their current Fedora tasks. The people
that don't get paid to work on Fedora are busy with their own work.
What are the chances that RH or some other Fedora-friendly corporation
would be able to dedicate someone's time to solving this problem? I
think that it'd need to be more than an intern or a Google SoC project
to make any real progress against the political hurdles.

Jeff

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-14-2008, 03:02 PM
"Jeffrey Ollie"
 
Default "Action Items" From FUDCon?

On 1/14/08, Jesse Keating <jkeating@redhat.com> wrote:
> On Mon, 14 Jan 2008 09:26:40 -0600
> "Jeffrey Ollie" <jeff@ocjtech.us> wrote:
>
> > I think that the least disruptive option is to enhance the tag
> > checking script to prevent moving or deleting CVS tags that have been
> > submitted to Koji for building. It's not a perfect solution because
> > CVS provides very weak guarantees of data integrity/consistency but it
> > may be "good enough".
>
> Except that you can just call cvs itself to do the tag manipulation,
> and that I don't think can be prevented.

Yes, which is why it isn't a perfect solution, but people seem to want
to band-aid CVS ("the devil they know") rather than move to something
that has a more elegant solution to this problem ("the devil they
don't know").

Jeff

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-14-2008, 03:22 PM
Matt Domsch
 
Default "Action Items" From FUDCon?

On Sun, Jan 13, 2008 at 06:28:55PM -0600, Mike McGrath wrote:
> Can anyone think of any action items the infrastructure team (or others
> for that matter) may need to do as a result of discussions during
> hackfest/fudcon?


Lots of little things came out of discussions I was in. Not all are
action items, just to ponder.


* MirrorManager mirrorlist needs to be able to provide the list of mirrors _by
protocol_. e.g append &proto={http,ftp,rsync} to get back the list of rsync
mirrors. Should be easy enough for me to add. Unity folks want
this.

* Promote/rebrand the Rescue ISO into the "Fedora Network-based
Installer". Needs trivial change (clumens will make) to use default
path download.fp.o/pub/fedora/.... This will allow users to get
started installing or upgrading by downloading only ~100MB instead
of ~700MB. Debate fate of boot.iso which lets people get started by
downloading only 8MB, knowing they need to download another 92MB
stage2 immediately during install too.

* follow-up - teach anaconda loader to parse a mirrorlist instead of
using a single default path. This provides better failover
capability and lets users choose which mirror they want.

* follow-up - anaconda doesn't have a way to mimic yum Ctrl-C to jump
to the next mirror in the mirrorlist in case you've hit a dud/slow
mirror. Would be nice to have.

* yum-avahi plugin, and some form of sharing. Think avahi query 'who
has foo-0.1.3-1.i386.rpm in your yum cache?', get back answers, and
download from that local user. Repo metadata could be done
likewise (it too is signed after all).

* UEFI support is shaping up thanks to PeterJ. Now to finish that in
time for F9.

* DaveJ had some good ideas for disabling unneeded syncs
during install (e.g. remount / as ext2 during install - no
reason to journal then, and mount as ext3 afterwards). Fix rpm so
it doesn't fsync() after writing each file to disk. Also fix the
syslogd so it doesn't fsync() after each line when writing out the
logs during bootup.


* Mock has gotten faster recently - enough so that we could probably
throw lots more builds at our build systems. One fallout is that
when a in the dependency tree changes, we could have koji kick off
scratch builds of all applications later in the dependency tree, to
discover compile-time breakage of those later applications. This
would let us catch these earlier. Some people do this already
themselves manually - I'm saying integrate it into koji. (If we need
to add more build servers, we can investigate.)


* With the re-invigorated marketing push, look for ways to get
additional sponsorship and to integrate sponsors into the Fedora
community (as opposed to merely asking for money).

* Improve Packaging around software licenses to more automate checking
for license compatibility (two apps separately licensed - are their
licenses compatible...)


-Matt

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-14-2008, 06:44 PM
Matt Domsch
 
Default "Action Items" From FUDCon?

On Sun, Jan 13, 2008 at 06:28:55PM -0600, Mike McGrath wrote:
> Can anyone think of any action items the infrastructure team (or others
> for that matter) may need to do as a result of discussions during
> hackfest/fudcon?

* FAS 1 and 2 make sure usernames can be >8 chars.

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-14-2008, 08:11 PM
"Paul W. Frields"
 
Default "Action Items" From FUDCon?

On Mon, 2008-01-14 at 10:22 -0600, Matt Domsch wrote:
> On Sun, Jan 13, 2008 at 06:28:55PM -0600, Mike McGrath wrote:
> > Can anyone think of any action items the infrastructure team (or others
> > for that matter) may need to do as a result of discussions during
> > hackfest/fudcon?
>
>
> Lots of little things came out of discussions I was in. Not all are
> action items, just to ponder.

Looking at your action list, I realized that I have many, many pages of
notes taken in various places to transcribe here. I only mentioned the
one that immediately came to mind for Infrastructure, but spreading the
rest out for consumption would be a good thing. More to come....

--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-15-2008, 08:40 AM
Michael Schwendt
 
Default "Action Items" From FUDCon?

On Mon, 14 Jan 2008 10:22:21 -0600, Matt Domsch wrote:

> * Mock has gotten faster recently - enough so that we could probably
> throw lots more builds at our build systems.

Can Koji deal with "lots more builds" in appropriate ways? Would it kill
(and later requeue) a low-priority build-job in favour of a more important
build-job?

[...]

It's the huge packages (e.g. openoffice, kernel or several MB of C++)
which occupy a build-host for a long time because compiling them takes
much more time than setting up a mock buildroot. When such build-jobs are
active, they slow down other builds on the same host significantly. Koji
tries to spread the load, but for "lots more builds", such as scratch and
debug builds, it would better use special spare servers if any of those
jobs ran for a long or unexpected period. Unless it can kill+requeue less
important builds automatically.

As Plague has gotten faster recently, too, and no longer chokes on
downloading build results, the build server load becomes more obvious.
Together with mock's caching of initial buildroots, the many small
packages now build in roughly one minute when a build-host is not too
busy. Examples in footnote [1]. But as soon as a builder runs a "heavy"
koji build-job in parallel, it can be seen how that slows down the
additional plague build-job:

http://buildsys.fedoraproject.org/build-status/job.psp?uid=37880
- xenbuilder2 took 5 minutes for i386/x86_64
- ppc2 took 19 minutes (!)

http://buildsys.fedoraproject.org/build-status/job.psp?uid=37878
- hammer2 took 1 minute for i386 (!)
- ppc2 took 3 minutes
- xenbuilder2 took 10 minutes for x86_64

http://buildsys.fedoraproject.org/build-status/job.psp?uid=37876
- ppc2 took 4 minutes
- xenbuilder2 took 10-11 minutes for i386/x86_64

The second example is most impressive. Plague doesn't choose hammer2 most
of the time, because with the current config it first occupies two of the
four slots on xenbuilder2 before using hammer2. It doesn't know either
when koji already uses a build-host. But I assume that koji builds are
slowed down similarly.

So, better not try to keep the build-hosts busy when that would increase
the average time of response for our packagers. The more free the builders
are, the faster a packager receives results for a build, even for a
helpful scratch-build of a package that compiles for 10-15 minutes till
it ends with an error.

--
[1]
http://buildsys.fedoraproject.org/build-status/job.psp?uid=37870
http://buildsys.fedoraproject.org/build-status/job.psp?uid=37875
http://buildsys.fedoraproject.org/build-status/job.psp?uid=37874
http://buildsys.fedoraproject.org/build-status/job.psp?uid=37865
http://buildsys.fedoraproject.org/build-status/job.psp?uid=37859
http://buildsys.fedoraproject.org/build-status/job.psp?uid=37853

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 

Thread Tools




All times are GMT. The time now is 11:30 AM.

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