Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Advisory Board (http://www.linux-archive.org/fedora-advisory-board/)
-   -   Dealing with PPC in Fedora 9(+) (http://www.linux-archive.org/fedora-advisory-board/12451-dealing-ppc-fedora-9-a.html)

David Woodhouse 12-04-2007 09:58 PM

Dealing with PPC in Fedora 9(+)
 
On Mon, 2007-11-12 at 14:58 -0500, Jesse Keating wrote:
> On Mon, 12 Nov 2007 14:40:31 -0500
> David Woodhouse <dwmw2@infradead.org> wrote:
>
> > I don't believe it's realistic to make changes to the hosting and
> > mirroring arrangements either -- let's stick with the plan of keeping
> > them in the 'normal tree' which you called a last resort.
> >
> > We'll plan to have each spin ready on time, so it can go out fairly
> > much synchronously with the i386 and x86_64 releases -- and more to
> > the point, with precisely the same package set. If for some reason we
> > slip, let's impose a rule that we may not ship any packages in the
> > PPC spin which are not in rawhide (for the RCs) or f9-updates (for
> > the release).
> >
> > OK?
>
> This seems a reasonable compromise all together. I can be happy with
> this for Fedora 9. Hopefully by the time 9 is let loose, we'll have
> had at least one other full fledged secondary arch up and running and
> proving that the method can work.

I suspect this is going to work a whole lot better if I have commit
access to anaconda, kudzu, rhpl, booty, etc.

At the moment, the round-trip time between me generating a patch to
something like kudzu and seeing it in a testable rawhide build is
somewhat suboptimal.

I don't mean to complain -- I know people are busy and have better
things to do than commit my patches and kick off builds so that I can
get on with testing rawhide. But people are going to be busy in the
run-up to te releases too, when I most want my fixes to be getting into
builds promptly.

So it's probably best if I can be a little more self-sufficient in that
respect, by having commit access to both upstream and package
repositories and being able to do builds (at least for rawhide). Please.

Actually, we've spoken often of "arch teams" having commit access to
_all_ packages. Is that feasible?

--
dwmw2

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

Josh Boyer 12-04-2007 11:17 PM

Dealing with PPC in Fedora 9(+)
 
On Tue, 04 Dec 2007 22:58:21 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

>
> On Mon, 2007-11-12 at 14:58 -0500, Jesse Keating wrote:
> > On Mon, 12 Nov 2007 14:40:31 -0500
> > David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > > I don't believe it's realistic to make changes to the hosting and
> > > mirroring arrangements either -- let's stick with the plan of keeping
> > > them in the 'normal tree' which you called a last resort.
> > >
> > > We'll plan to have each spin ready on time, so it can go out fairly
> > > much synchronously with the i386 and x86_64 releases -- and more to
> > > the point, with precisely the same package set. If for some reason we
> > > slip, let's impose a rule that we may not ship any packages in the
> > > PPC spin which are not in rawhide (for the RCs) or f9-updates (for
> > > the release).
> > >
> > > OK?
> >
> > This seems a reasonable compromise all together. I can be happy with
> > this for Fedora 9. Hopefully by the time 9 is let loose, we'll have
> > had at least one other full fledged secondary arch up and running and
> > proving that the method can work.
>
> I suspect this is going to work a whole lot better if I have commit
> access to anaconda, kudzu, rhpl, booty, etc.
>
> At the moment, the round-trip time between me generating a patch to
> something like kudzu and seeing it in a testable rawhide build is
> somewhat suboptimal.
>
> I don't mean to complain -- I know people are busy and have better
> things to do than commit my patches and kick off builds so that I can
> get on with testing rawhide. But people are going to be busy in the
> run-up to te releases too, when I most want my fixes to be getting into
> builds promptly.
>
> So it's probably best if I can be a little more self-sufficient in that
> respect, by having commit access to both upstream and package
> repositories and being able to do builds (at least for rawhide). Please.
>
> Actually, we've spoken often of "arch teams" having commit access to
> _all_ packages. Is that feasible?

Perhaps with FAS2. I don't believe it is right now. Though
considering I have commit access to everything already, adding you
would cover the whole team!

josh

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

Jeremy Katz 12-05-2007 02:29 AM

Dealing with PPC in Fedora 9(+)
 
On Tue, 2007-12-04 at 22:58 +0000, David Woodhouse wrote:
> On Mon, 2007-11-12 at 14:58 -0500, Jesse Keating wrote:
> > This seems a reasonable compromise all together. I can be happy with
> > this for Fedora 9. Hopefully by the time 9 is let loose, we'll have
> > had at least one other full fledged secondary arch up and running and
> > proving that the method can work.
>
> I suspect this is going to work a whole lot better if I have commit
> access to anaconda, kudzu, rhpl, booty, etc.

I'm just going to come right out and say that if Fedora as a project
starts dictating commit access to hosted "upstream" projects, that's a
quick way to kill the use of Fedora for hosting upstream projects.
Because that's not the way that commit access for projects should be
given. Ever.

> At the moment, the round-trip time between me generating a patch to
> something like kudzu and seeing it in a testable rawhide build is
> somewhat suboptimal.

Getting rawhide builds at all right now is a bit of a challenge all its
own with the openssl/openldap rev :)

> I don't mean to complain -- I know people are busy and have better
> things to do than commit my patches and kick off builds so that I can
> get on with testing rawhide. But people are going to be busy in the
> run-up to te releases too, when I most want my fixes to be getting into
> builds promptly.

Actually, run up to release is easier because it's "bug-fix mode" time
rather than "integrate huge new chunks of code" time. Especially when
some of the changes underway are directly related to the change that
you're also wanting to do.

And < a day of turnaround for the most recent one really isn't bad.
Also, there is a member of what is ostensibly the ppc team (pnasrat) who
does have commit access to most of the above.

> So it's probably best if I can be a little more self-sufficient in that
> respect, by having commit access to both upstream and package
> repositories and being able to do builds (at least for rawhide). Please.
>
> Actually, we've spoken often of "arch teams" having commit access to
> _all_ packages. Is that feasible?

There's a very large difference between "committing to packages" and
"committing to upstream". We don't have a great way of doing the "arch
maintainers can commit to any package", but since we're not talking
about huge numbers of arch teams, we could probably go with the quick
answer (just adding people to cvsadmin)

Jeremy

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

Josh Boyer 12-05-2007 02:43 AM

Dealing with PPC in Fedora 9(+)
 
On Tue, 04 Dec 2007 22:29:38 -0500
Jeremy Katz <katzj@redhat.com> wrote:

> On Tue, 2007-12-04 at 22:58 +0000, David Woodhouse wrote:
> > On Mon, 2007-11-12 at 14:58 -0500, Jesse Keating wrote:
> > > This seems a reasonable compromise all together. I can be happy with
> > > this for Fedora 9. Hopefully by the time 9 is let loose, we'll have
> > > had at least one other full fledged secondary arch up and running and
> > > proving that the method can work.
> >
> > I suspect this is going to work a whole lot better if I have commit
> > access to anaconda, kudzu, rhpl, booty, etc.
>
> I'm just going to come right out and say that if Fedora as a project
> starts dictating commit access to hosted "upstream" projects, that's a
> quick way to kill the use of Fedora for hosting upstream projects.
> Because that's not the way that commit access for projects should be
> given. Ever.

So not to nit-pick, but nobody was dictating commit access. David
simply said it would be smoother if he had it.

And that aside, it is often quite common for upstream projects to have
architecture "maintainers" for common code bases. I don't see how the
"Fedora hostedness" of this plays into it at all. An upstream is an
upstream no matter where it's hosted.

> And < a day of turnaround for the most recent one really isn't bad.
> Also, there is a member of what is ostensibly the ppc team (pnasrat) who
> does have commit access to most of the above.

Having Paul help out would work, sure. Whether he's willing to do that
I have no idea. (Though it would be awesome if so.)

josh

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

Jeremy Katz 12-05-2007 02:52 AM

Dealing with PPC in Fedora 9(+)
 
On Tue, 2007-12-04 at 21:43 -0600, Josh Boyer wrote:
> On Tue, 04 Dec 2007 22:29:38 -0500 Jeremy Katz <katzj@redhat.com> wrote:
> > On Tue, 2007-12-04 at 22:58 +0000, David Woodhouse wrote:
> > > On Mon, 2007-11-12 at 14:58 -0500, Jesse Keating wrote:
> > > > This seems a reasonable compromise all together. I can be happy with
> > > > this for Fedora 9. Hopefully by the time 9 is let loose, we'll have
> > > > had at least one other full fledged secondary arch up and running and
> > > > proving that the method can work.
> > >
> > > I suspect this is going to work a whole lot better if I have commit
> > > access to anaconda, kudzu, rhpl, booty, etc.
> >
> > I'm just going to come right out and say that if Fedora as a project
> > starts dictating commit access to hosted "upstream" projects, that's a
> > quick way to kill the use of Fedora for hosting upstream projects.
> > Because that's not the way that commit access for projects should be
> > given. Ever.
>
> So not to nit-pick, but nobody was dictating commit access. David
> simply said it would be smoother if he had it.

It read a lot like "Fedora the project should dictate commit access to
some of the hosted projects"

> And that aside, it is often quite common for upstream projects to have
> architecture "maintainers" for common code bases. I don't see how the
> "Fedora hostedness" of this plays into it at all. An upstream is an
> upstream no matter where it's hosted.

It's more the matter that Fedora as a project should *not* be in the
business of micro-managing the commit policies of those who choose to
host with us. If, eg, glibc were hosted here, would you expect that
glibc commit access would be given just because the Fedora Board says
so? I wouldn't. Commit access to an upstream project is given based on
the merit of patches sent and received by said source base.

Jeremy

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

Josh Boyer 12-05-2007 03:12 AM

Dealing with PPC in Fedora 9(+)
 
On Tue, 04 Dec 2007 22:52:22 -0500
Jeremy Katz <katzj@redhat.com> wrote:

> On Tue, 2007-12-04 at 21:43 -0600, Josh Boyer wrote:
> > On Tue, 04 Dec 2007 22:29:38 -0500 Jeremy Katz <katzj@redhat.com> wrote:
> > > On Tue, 2007-12-04 at 22:58 +0000, David Woodhouse wrote:
> > > > On Mon, 2007-11-12 at 14:58 -0500, Jesse Keating wrote:
> > > > > This seems a reasonable compromise all together. I can be happy with
> > > > > this for Fedora 9. Hopefully by the time 9 is let loose, we'll have
> > > > > had at least one other full fledged secondary arch up and running and
> > > > > proving that the method can work.
> > > >
> > > > I suspect this is going to work a whole lot better if I have commit
> > > > access to anaconda, kudzu, rhpl, booty, etc.
> > >
> > > I'm just going to come right out and say that if Fedora as a project
> > > starts dictating commit access to hosted "upstream" projects, that's a
> > > quick way to kill the use of Fedora for hosting upstream projects.
> > > Because that's not the way that commit access for projects should be
> > > given. Ever.
> >
> > So not to nit-pick, but nobody was dictating commit access. David
> > simply said it would be smoother if he had it.
>
> It read a lot like "Fedora the project should dictate commit access to
> some of the hosted projects"

Odd. I haven't seen that anywhere.

> > And that aside, it is often quite common for upstream projects to have
> > architecture "maintainers" for common code bases. I don't see how the
> > "Fedora hostedness" of this plays into it at all. An upstream is an
> > upstream no matter where it's hosted.
>
> It's more the matter that Fedora as a project should *not* be in the
> business of micro-managing the commit policies of those who choose to
> host with us. If, eg, glibc were hosted here, would you expect that
> glibc commit access would be given just because the Fedora Board says
> so? I wouldn't. Commit access to an upstream project is given based on
> the merit of patches sent and received by said source base.

Sure, of course. Perhaps the fact that it's being discussed on the FAB
list gave you the impression that the Board was somehow being invoked,
but I just attributed that as David continuing a thread. Not asking
for the Board to dictate anything.

At any rate, I think we're saying mostly the same things and our
confusions are coming from different interpretations of David's
remarks. Or maybe it's because it's late and I'm tired. Regardless,
I'll be quiet.

josh

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

David Woodhouse 12-05-2007 11:00 AM

Dealing with PPC in Fedora 9(+)
 
On Tue, 2007-12-04 at 22:29 -0500, Jeremy Katz wrote:
> On Tue, 2007-12-04 at 22:58 +0000, David Woodhouse wrote:
> > On Mon, 2007-11-12 at 14:58 -0500, Jesse Keating wrote:
> > > This seems a reasonable compromise all together. I can be happy with
> > > this for Fedora 9. Hopefully by the time 9 is let loose, we'll have
> > > had at least one other full fledged secondary arch up and running and
> > > proving that the method can work.
> >
> > I suspect this is going to work a whole lot better if I have commit
> > access to anaconda, kudzu, rhpl, booty, etc.
>
> I'm just going to come right out and say that if Fedora as a project
> starts dictating commit access to hosted "upstream" projects, that's a
> quick way to kill the use of Fedora for hosting upstream projects.
> Because that's not the way that commit access for projects should be
> given. Ever.

Yes, that's very true. It would be very silly.

Josh is right, however -- I wasn't asking the Board to mandate it. I was
just continuing the thread because it started here. Sorry if I was
unclear.

> > At the moment, the round-trip time between me generating a patch to
> > something like kudzu and seeing it in a testable rawhide build is
> > somewhat suboptimal.
>
> Getting rawhide builds at all right now is a bit of a challenge all its
> own with the openssl/openldap rev :)

This is also true.

> > I don't mean to complain -- I know people are busy and have better
> > things to do than commit my patches and kick off builds so that I can
> > get on with testing rawhide. But people are going to be busy in the
> > run-up to te releases too, when I most want my fixes to be getting into
> > builds promptly.
>
> Actually, run up to release is easier because it's "bug-fix mode" time
> rather than "integrate huge new chunks of code" time. Especially when
> some of the changes underway are directly related to the change that
> you're also wanting to do.

Perhaps so. Can I hold you to that? :)

> And < a day of turnaround for the most recent one really isn't bad.

That's true; thanks for that. I think it's the fastest I've ever managed
to get such a patch applied -- it makes me wonder if I should have been
submitting patches with a tempting 'FIXME' in them all along... :)

Unfortunately, it still isn't in a built anaconda package -- and even if
it was, that anaconda package would have been built against
kudzu-1.2.80, which still lacks the changes I made last week.

Again, I should point out that I don't mean to criticise. I'd just like
to find a way to improve the situation without constantly having to
badger people to commit stuff for me and build stuff for me.

> Also, there is a member of what is ostensibly the ppc team (pnasrat) who
> does have commit access to most of the above.

If Paul is happy to be bothered and will respond in good time, that
works for me. Paul, can you get a kudzu into rawhide with my latest
changes please (which I think are all now in kudzu upstream cvs; thanks
Bill)?

> > So it's probably best if I can be a little more self-sufficient in that
> > respect, by having commit access to both upstream and package
> > repositories and being able to do builds (at least for rawhide). Please.
> >
> > Actually, we've spoken often of "arch teams" having commit access to
> > _all_ packages. Is that feasible?
>
> There's a very large difference between "committing to packages" and
> "committing to upstream".

Yes, there is. From my point of view, I would settle just for committing
to packages. I could add patches then -- after I submit them upstream of
course.

Since the packages I was thinking of tend to ship without _any_ patches,
because we _are_ upstream for them and we tend to just ship a new
tarball for each build, I'm not sure that's the best answer -- hence the
request for upstream access too, for those packages.

> We don't have a great way of doing the "arch
> maintainers can commit to any package", but since we're not talking
> about huge numbers of arch teams, we could probably go with the quick
> answer (just adding people to cvsadmin)

That would be great; yes please.

(Although I don't feel wonderfully happy about accepting such rights for
myself alone when I feel strongly that _all_ Fedora contributors should
be able to commit to all packages. It's not as if we can't revert stuff,
and can't promote an attitude of violence towards people who abuse the
privilege, like we already have.)

--
dwmw2

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

Bill Nottingham 12-05-2007 04:21 PM

Dealing with PPC in Fedora 9(+)
 
David Woodhouse (dwmw2@infradead.org) said:
> > Also, there is a member of what is ostensibly the ppc team (pnasrat) who
> > does have commit access to most of the above.
>
> If Paul is happy to be bothered and will respond in good time, that
> works for me. Paul, can you get a kudzu into rawhide with my latest
> changes please (which I think are all now in kudzu upstream cvs; thanks
> Bill)?

I can do a release - it's just that at the moment I'm working on making
those changes obsolete. It's just taking longer than I thought. :/

Bill

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

David Woodhouse 12-07-2007 03:01 PM

Dealing with PPC in Fedora 9(+)
 
On Wed, 2007-12-05 at 12:21 -0500, Bill Nottingham wrote:
> David Woodhouse (dwmw2@infradead.org) said:
> > > Also, there is a member of what is ostensibly the ppc team (pnasrat) who
> > > does have commit access to most of the above.
> >
> > If Paul is happy to be bothered and will respond in good time, that
> > works for me. Paul, can you get a kudzu into rawhide with my latest
> > changes please (which I think are all now in kudzu upstream cvs; thanks
> > Bill)?
>
> I can do a release - it's just that at the moment I'm working on making
> those changes obsolete. It's just taking longer than I thought. :/

Thanks. There seems to have been a subsequent anaconda build too, which
is useful.

Now, if we could just have booty and rhpl built, and maybe even an rhpxl
with bug #374201 fixed... then it'd just be standard rawhide breakage
which gets in my way :)

--
dwmw2

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


All times are GMT. The time now is 09:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.