Re: [gentoo-dev] [ANNOUNCE] bayesiam SPAM filter 'bogofilter' ebuild on bugzilla

[Evan Read]

On 2002.11.09 14:38 George Shapovalov wrote:
> Hey Evan, Javier and everybody.
>
> So this issue came up again, yet another time (TM) :).
> Please take a look at #1523. That describes some thoughts and certain
> strategy
> that is designed to help exactly this.

Interesting.  Your thoughts on offloading "non-critical" tasks to users 
probably is the solution much more than changing the infrastructure.

My beef is the length of time things sit in bugzilla waiting for 
inclusion.  Are there meant to be numerous comments on the bug talking 
of success before things will get into the tree?

> the now-ultimate solution will involve streamlined ebuild
> sbmission/processing that will allow fast turnover and wide-scale
> testing
> that you are proposing here. Comments are wellcome (specifically the

How about this for a suggestion:

I know that nobody wants to duplicate effort etc, but would it be 
possible to break the portage tree up (one tree, many dirs)?

Maybe I am thinking too much about the debian scenario, but what do 
people think of having something like:

/usr/portage/stable
/usr/portage/testing
/usr/portage/unstable

This would be a single tree, but a new option (which would remove 
keywords, I guess - sorry ;) in make.conf (or wherever) would be 
"DEFAULT_TREE=".

So one could track the stable, testing or unstable tree.  To select a 
package outside your default tree would be something like:

# emerge --unstable bogofilter

There would be duplication of ebuilds, but they are only small 
anyways.  Different versions would exist in different places.  If there 
was only a stable version, and no testing versions where available, 
then something like

"Package not found in unstable tree" would come up.

Users could submit ebuilds (like my judy and bogofilter - and the 
folding@home one I am thinking of doing) that could be checked in by a 
core developer after they have verified it isn't majorly screwed.  In 
otherwords, it hits the tree if it builds and installs (even if rough - 
price you pay for --unstable).

Then it could sit in unstable where people could test it and put 
suggestions against it.  We could use existing infrastructure, things 
would get into the tree so much faster, and masking and keywords 
wouldn't be required.  By all means, append comments to buzilla bugs to 
indicate how good the package is.

The idea isn't to change the way things are done, just provide a way to 
get stuff into the tree.

>   In the mean time it is possible to announce new ebuilds here, how
> this is
> done now.

Possible to auto mate the announcement of ebuilds from new bugs in 
buzilla under "ebuild" category?  Subscribe to 
new-ebuild-announce@g.o?

> Hereby I would like to ask anybody willing to do some testing (and not
> afraid
> of bad effects of course ;)), to try out new ebuilds which have "~"
> for their

So, enable: #ACCEPT_KEYWORDS="~arch"?

Perhaps the developers could publish a checklist of things that users 
could do?

So in bugzilla, they could comment on each thing and say "works" or 
"fails".  Things like successful install, removal etc to test the 
ebuild functions springs to mind.  If rc scripts come with it, checks 
for stopping and starting successfully could also work.

Also a suggestion to check for upstream bugs for anything release 
critical.

Developers, teach us ;)

> ARCH in the KEYWORDS and report results. The best way to report at
> present is
> to find the related bug (just a quick search on bugzilla) and post a
> message
> there (do not be afraid if the bug is closed - core developer will be
> glad to
> hear about success and will remove "~" onces he accumulates anough
> feedback).

If that feedback could be documented, and the process required defined, 
that would be great.

It would also be great if a statement about "this is what keeps ebuilds 
out of the tree" would also be good.  What is needed to satisfy the 
core team?

Thanks.

Evan.

--
gentoo-dev@g.o mailing list