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

[George Shapovalov]

Hi

On Friday 08 November 2002 21:37, Evan Read wrote:
> On 2002.11.09 14:38 George Shapovalov wrote:
> 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?
Not really. The ebuiod gets committed as soon as core developer finishes 
processing it. The difference is that the ebuild is masked at this stage. 
Original system only had one way of masking - via package.mask. Now we have 
KEYWORDS based masking that allows to handle "testing" profile.
However multiple success reports do help - upon collecting anough feedback 
core developer will remove "~" from keywords against appropriate arch and the 
ebuild will be considered stable at this point.
   In order to be able to automatize this process further we need to have one 
more layer of stability, to get the full "new -> user_approved/testing or 
unstable (depending on user feedback) -> stable" logic. Most importantly we 
need to have polished feedback collection mechanism implemented and tested.
   After that this is a (relatively simple) matter of creating an automated 
ebuild submission process. After that core developers will have their 
responsibility in core/approved packages (stable profile). General developers 
(or in other terminology "active users" such as yourself) will have their 
playground with fast turnover of submitted/corrected ebuilds. And "normal 
users" who actually want to just use the system will be able to pick the 
profle that suits their idea of what they want.

>
> > 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)?
Well, any breakage creates the duplication. This has been discussed numerous 
times before. If you are interested in prior discussion please search 
gentoo-dev for "unstable branch", "streamlined ebuild processing" and my 
name, all whthin this year. So far I did not see better way proposed that 
would help all the points raised. I think the most constructive way would be 
to post or at least CC any new ideas to that bug (provided this was not 
mentioned on the bug discussion before of course). This way we will have all 
ideas "registered".


> 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=".
Well, thats just an alternative way of providing part of that functionality, 
namely stability related aspects. KEYWORDS do that and in addition cover few 
more important issues, such as various arch specific stuff and is in general 
very basic and therefore very extensuble concept. Just try to go through this 
concept once more ;), you'll see it covers this issue (one more level and a 
bit of tuning is necessary, but I must admit this is much more extensible 
than any specialised method).

>
> 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
Yep, istead you just add ~arch and/or Xarch (when we have one more stability 
level implemented) to your ALLOWED_KEYWORDS or we can provide equivalent 
option to emerge.

BTW, one thing that will get eventually done is partial portage-tree checkout. 
This point was raised few times, but no final decision was done yet (proposed 
divisions being according to: profile (secure/stable/desktop...), arch or 
what else?).

> 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).
Yep. This is the idea behind the proposal in that bug: the ebuild gets 
committed automatically if it passes certain requirements (i.e it is 
*already* in the tree and thus is available, just has a special stability 
status). If it gets sufficient amount of user test-reports it gets some kind 
of "checked" status. At which point it can be considered more stable than 
"new" or even be included in the core-developer list of ebuilds to be 
processed. Alternatively core developers may be processing only the ebuilds 
that accumulated sufficient amount of success reports *and* "wanted 
requests".

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

> >   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?
Well, AFAIK bugzilla this is not so easy. We will get something better 
somewhat later. AFAICT the [serious] work on new bug processing system will 
start after we will get 1.4 install CDs out of the door. However I think we 
will get automated ebuild processing system approx. within the same time 
frame, so this point will probably be covered by then anyway.

> > 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"?
Yes.

> Perhaps the developers could publish a checklist of things that users
> could do?
   In terms of creating ebuilds there are various docs. May be one thing to 
add (or rahter reiterate) - *use lintool* !!!!!! (this is a separate package 
now). This is the tool to check ebuilds for consistency and compliance with 
present requirements. And it gets updated quite often.
   In terms of ebuild testing thats harder - this is a moving goal, as this 
area is in active development. But most importantly - user feedback is 
eagerly needed, just as I outlined: please check whatever ebuilds that have 
~arch that you are interested in and report results to the developer who 
committed it. When we will have automated report system working we will have 
the corresponding doc.

> 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.
Exactly.

> Also a suggestion to check for upstream bugs for anything release
> critical.
>
> Developers, teach us ;)
Yep. This is a very valid point. And we are working on the docs very hard. Its 
just as usual - there is so much exciting stuff, so that it is hard to keep 
the docs in sync. Though I should say this is amaising that the docs do not 
lag behind too much with this distro (at least not as much as I was used to 
:)). But of course any help to our doc team is wellcome :).

Ok, the last part would be the reiteration of what I just said, so I guess 
I'll stop here. In short: the real solutions are in the works and will 
require few more month. Right now you can use the last paragraph of my last 
message as a "test results reporting guide during the transition period". In 
general - important updates are announced on the web page, so please check it 
periodically. 
Also you can take a look at the app-admin/gentoo-stats. This collects various 
info about gentoo installations (opt-in of course  - you have to specifically 
emerge it), among other things the list of installed packages. It can be used 
to monitor success of package use to some extent... (as a last resort 
substitute IMHO).

George

--
gentoo-dev@g.o mailing list