| 1 |
Hey Evan, Javier and everybody. |
| 2 |
|
| 3 |
So this issue came up again, yet another time (TM) :). |
| 4 |
Please take a look at #1523. That describes some thoughts and certain strategy |
| 5 |
that is designed to help exactly this. |
| 6 |
|
| 7 |
As Evan says (and I and many developers would agree) separate tree has its |
| 8 |
disadvantages. Most important one being duplication of effort and encumbered |
| 9 |
transition of packages between trees. It is much better to extend present |
| 10 |
ebuild handling model to have multiple stability levels within the same |
| 11 |
portage tree. We already have keyword based masking - effectively we already |
| 12 |
have stable and testing profiles. More work needs to be done of course, but |
| 13 |
the now-ultimate solution will involve streamlined ebuild |
| 14 |
sbmission/processing that will allow fast turnover and wide-scale testing |
| 15 |
that you are proposing here. Comments are wellcome (specifically the desing |
| 16 |
of user feedback/voting system is most eagerly needed now). Just be careful |
| 17 |
reading that bug: it is somewhat outdated by now - it contains some mechanism |
| 18 |
descriptions which more as a "test-bed", now we have this functionality |
| 19 |
implemented slightly differently (e.g. KEYWORDS instead of levels). |
| 20 |
In the mean time it is possible to announce new ebuilds here, how this is |
| 21 |
done now. |
| 22 |
|
| 23 |
Along these lines I would like to voice my request here: |
| 24 |
As I mentioned we now have a keyword based masking providing a test-oriented |
| 25 |
profile. Eventually we will have some more/less automated report system, |
| 26 |
however we need to make sure new submissions are getting enough testing |
| 27 |
*now*, so that the "~"'s do not stay on ebuilds forever. |
| 28 |
Hereby I would like to ask anybody willing to do some testing (and not afraid |
| 29 |
of bad effects of course ;)), to try out new ebuilds which have "~" for their |
| 30 |
ARCH in the KEYWORDS and report results. The best way to report at present is |
| 31 |
to find the related bug (just a quick search on bugzilla) and post a message |
| 32 |
there (do not be afraid if the bug is closed - core developer will be glad to |
| 33 |
hear about success and will remove "~" onces he accumulates anough feedback). |
| 34 |
|
| 35 |
George |
| 36 |
|
| 37 |
|
| 38 |
On Friday 08 November 2002 18:14, Evan Read wrote: |
| 39 |
> If I may chime in: |
| 40 |
> > As I also said in that e-mail I sent to Evan, don't you think a better |
| 41 |
> > interface to commit new ebuilds, being considered for inclusion in the |
| 42 |
> > official tree, or just to use by those willing to try out something |
| 43 |
> |
| 44 |
> I think our own CVS repository for our own ebuilds would be nice. That |
| 45 |
> way users would only need to "emerge alt-ebuilds" to pull down a tree |
| 46 |
[skipped] |
| 47 |
> But then, buzilla would be better if stuff moved into the repository |
| 48 |
> much faster! I am sure my ebuilds could go in (even better, put in |
| 49 |
> Javier's) with a "testing" or even mask them. They have been waiting |
| 50 |
> weeks. |
| 51 |
> |
| 52 |
> So an alternate tree has its disadvantages. We could keep one if |
| 53 |
> bugzilla was streamlined. But I am using a number of ebuilds I have |
| 54 |
> gotten from bugzilla. Much nicer to get ones out of masking. |
| 55 |
[skipped] |
| 56 |
> |
| 57 |
> Evan. |
| 58 |
|
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-dev@g.o mailing list |
Archives