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 > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-16-2011, 10:21 AM
Agostino Sarubbo
 
Default making the stable tree more up-to-date

On Friday 16 December 2011 06:10:13 Anthony G. Basile wrote:
> Does your script do any checking on the quality of the ebuild, eg that
> it respects C/LDFLAGS. If so, that's useful and would help package
> maintainers to better prepare their ebuilds for stabilization.
Unfortunately no.

For LDFLAGS there is a QA warning and is enough visible
For CFLAGS I see with the naked eye a bit of build log
My script at "end of work" just runs repoman full and cat entire ebuild( so,
imho, should be a tasks already done by maintainers).
Finally, I take a look at the ebuild to see if there are issue(s)

This is all.

> And congrats on making dev
Thanks


Regards
Agostino
 
Old 12-16-2011, 10:46 AM
justin
 
Default making the stable tree more up-to-date

On 12/16/11 12:21 PM, Agostino Sarubbo wrote:
> On Friday 16 December 2011 06:10:13 Anthony G. Basile wrote:
>> Does your script do any checking on the quality of the ebuild, eg that
>> it respects C/LDFLAGS. If so, that's useful and would help package
>> maintainers to better prepare their ebuilds for stabilization.
> Unfortunately no.
>
> For LDFLAGS there is a QA warning and is enough visible
> For CFLAGS I see with the naked eye a bit of build log
> My script at "end of work" just runs repoman full and cat entire ebuild( so,
> imho, should be a tasks already done by maintainers).
> Finally, I take a look at the ebuild to see if there are issue(s)
>
> This is all.
>
>> And congrats on making dev
> Thanks
>
>
> Regards
> Agostino

You can use the post* hooks for that. For FLAGS mixing I am using CFLAGS
and CXXFLAGS specific warning flags during compilation and grep for the
gcc mixing warning in the build log. Probably similar things can be done
for other problematic points. There was also a more sophisticated
approach Diego blogged about.

For respecting C/CXXFLAGS there was something Donnie suggested long ago.
If you use -frecord-gcc-switches you are able to read the used LFGAS
with eu-readelf.

Probably someone likes to put this together in a guideline how to check
a package correctly.

justin
 
Old 12-16-2011, 12:27 PM
"Paweł Hajdan, Jr."
 
Default making the stable tree more up-to-date

On 12/16/11 11:42 AM, justin wrote:
> I really like that you open all those bugs. But it makes no sense to
> add arches after a "time out". At least not after a such a short
> one.

I'm sorry this has annoyed/upset you. Let me just point out some facts:

- in November I first wrote about this new "more stabilizations" thing,
and included a list of ~800 packages, including many sci- ones
(<http://archives.gentoo.org/gentoo-dev/msg_a8d47428737e600238e3ad3d60f79208.xml>).
I don't remember any complains from the sci- maintainers then.

- people complain that a week-long timeout is too short, while after I
CC arches the answer often comes within minutes.

- actually in this case you've said "go ahead" for the bugs filed (thank
you!), so I don't fully understand the concerns here

- the bugs get filed when a package's most recent version has spent 6
months in ~arch, has _no_ open bugs, and is not a beta/alpha/rc/whatever
version. Many packages for which I filed bugs spent in ~arch a year or more.

> The maintainer is responsible for the package, that means it is
> their responsibility to decide that a package should go stable.

Packages with stable versions a year behind suggest this is not always
the case. Furthermore, most maintainers are happy about those
stabilizations (or tools), and users also like it.

> In addition they have to make the package fit to the standards that
> the arch teams request.

There are standards and nits. We frequently stabilize a package if only
nits are present.

> So as long as you don't review the packages yourself, consider a
> different proceeding than this timeout.

See the conditions above that packages have to meet to be included in
the stabilization list. I consider that an adequate review, and I know
arch developers and testers who look at the ebuilds.

It's always possible to close the bug if the package is deemed not ready.

> Please remove all added arches from the packages maintained by all
> sci* teams.

I can do that, but are you sure? I noted you've commented "go ahead"
on many of those (thank you!) - how about those bugs?
 
Old 12-16-2011, 12:53 PM
Rich Freeman
 
Default making the stable tree more up-to-date

On Fri, Dec 16, 2011 at 8:27 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> - people complain that a week-long timeout is too short, while after I
> CC arches the answer often comes within minutes.

So, I agree with pretty-much everything you said, and I completely
agree that stable-by-default, object-if-you-care is the right move.
That said, there is probably room for debate over the length of time
we leave the bug open. Maybe a week isn't quite long enough - maybe
two weeks is better.

Then again, if I as a maintainer had reservations I'd be very likely
to at least post a comment within a week even if I couldn't actually
resolve the issue decisively in that time.

Rich
 
Old 12-16-2011, 01:05 PM
"Andreas K. Huettel"
 
Default making the stable tree more up-to-date

>
> That said, there is probably room for debate over the length of time
> we leave the bug open. Maybe a week isn't quite long enough - maybe
> two weeks is better.
>

I'd like to support that suggestion. The new process is a great thing, just
give us a little bit more time to respond please...

(Not everyone who is busy immediately makes a devaway entry, but things may
delay anyway...)

Cheers, A

--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing
 
Old 12-16-2011, 01:12 PM
justin
 
Default making the stable tree more up-to-date

On 12/16/11 2:27 PM, "Paweł Hajdan, Jr." wrote:
> On 12/16/11 11:42 AM, justin wrote:
>> I really like that you open all those bugs. But it makes no sense to
>> add arches after a "time out". At least not after a such a short
>> one.
>
> I'm sorry this has annoyed/upset you. Let me just point out some facts:
>
> - in November I first wrote about this new "more stabilizations" thing,
> and included a list of ~800 packages, including many sci- ones
> (<http://archives.gentoo.org/gentoo-dev/msg_a8d47428737e600238e3ad3d60f79208.xml>).
> I don't remember any complains from the sci- maintainers then.
>
> - people complain that a week-long timeout is too short, while after I
> CC arches the answer often comes within minutes.
>
> - actually in this case you've said "go ahead" for the bugs filed (thank
> you!), so I don't fully understand the concerns here
>
> - the bugs get filed when a package's most recent version has spent 6
> months in ~arch, has _no_ open bugs, and is not a beta/alpha/rc/whatever
> version. Many packages for which I filed bugs spent in ~arch a year or more.
>
>> The maintainer is responsible for the package, that means it is
>> their responsibility to decide that a package should go stable.
>
> Packages with stable versions a year behind suggest this is not always
> the case. Furthermore, most maintainers are happy about those
> stabilizations (or tools), and users also like it.
>
>> In addition they have to make the package fit to the standards that
>> the arch teams request.
>
> There are standards and nits. We frequently stabilize a package if only
> nits are present.
>
>> So as long as you don't review the packages yourself, consider a
>> different proceeding than this timeout.
>
> See the conditions above that packages have to meet to be included in
> the stabilization list. I consider that an adequate review, and I know
> arch developers and testers who look at the ebuilds.
>
> It's always possible to close the bug if the package is deemed not ready.
>
>> Please remove all added arches from the packages maintained by all
>> sci* teams.
>
> I can do that, but are you sure? I noted you've commented "go ahead"
> on many of those (thank you!) - how about those bugs?
>

I really, really appreciate this push you give towards more stable trees
and I don't think sci teams dislike this. The only thing I want is some
time to review the packages before I sent them to the arch teams. And as
I said before, it would have been better if I would have dropped a short
comment on the bugs telling that they are in progress.

The recent "go aheads" were simply that I found time to review the one
or other bug.

So lets agree that your proceeding is worth the effort, but extend the
time you give the maintainer to iron their packages.

justin
 
Old 12-16-2011, 05:40 PM
Tim Harder
 
Default making the stable tree more up-to-date

On 2011-12-16 Fri 06:05, Andreas K. Huettel wrote:
> > That said, there is probably room for debate over the length of time
> > we leave the bug open. Maybe a week isn't quite long enough - maybe
> > two weeks is better.

When you do timeout a bug and assign it to arches, it would be great if
you could assign it to *all* previously stable arches, not just x86 and
amd64.

I've reopened a few timed out bugs to add missing arches so arch teams
can either drop keywords or stabilize. That way the tree as a whole can
slowly improve rather then just letting x86/amd64 rocket ahead while
having to keep all the old and often deprecated packages around anyway
for all the other stable arches.

Thanks,
Tim
 
Old 12-17-2011, 02:25 PM
"Paweł Hajdan, Jr."
 
Default making the stable tree more up-to-date

On 12/16/11 3:12 PM, justin wrote:
> So lets agree that your proceeding is worth the effort, but extend the
> time you give the maintainer to iron their packages.

Sounds good, looks like other people have similar comments about this.
I'll do that, thank you for feedback.
 

Thread Tools




All times are GMT. The time now is 07:19 AM.

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