Gentoo Archives: gentoo-dev

From: George Shapovalov <georges@×××××××××××.edu>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Unstable branch proposal - second round
Date: Sat, 16 Mar 2002 19:13:28
Message-Id: 200203170109.RAA00102@chamber.cco.caltech.edu
In Reply to: Re: [gentoo-dev] Unstable branch proposal - second round by Michael Lang
1 Got this message after I answered previous :-).
2 It looks like the proposal will address the issue you are concerned with. If
3 user selects to see unstable (confirmed or even all) packages he will
4 download all these ebuild on the next rsync and then will be able to use
5 gentool or gentoolkit on local copy!
6
7 George
8
9 On Tuesday 16 April 2002 17:33, you wrote:
10 > hmmm...I never intended to imply that the ebuild repository and bugs
11 > wouldn't be integrated....only that the avg joe downloader wouldn't be
12 > forced to learn a developer tool and that the ebuild repository would
13 > automatically push issues into the bugs database.
14 >
15 > To take this step up another notch, when bugs are fixed for a particular
16 > package, the issues surrounding the bug are suppressed to just a link
17 > called "past bugs" but when a bug is actively open, then the issues for
18 > that bug are displayed prominently for the end user so he can quickly
19 > determine if the package is going to meet his needs.
20 >
21 > This is something that would be most important to me as a new Linux
22 > user...I'm trying to find
23 > good quality packages and I know little about their background, but if I
24 > can read comments about them and see that there are bug issues at the
25 > moment, I can choose to move on to another package or attempt to work
26 > around the known bug issues.
27 >
28 > Michael
29 >
30 > At 01:26 AM 3/17/2002 +0100, you wrote:
31 > >On Saturday 16 March 2002 23:09, Brent Cook wrote:
32 > > > Do you essentially mean http://www.freshports.org/ with
33 > > > comments?
34 > >
35 > >that's cool, but imho there should be some way to leverage
36 > >bugs.gentoo.org by integrating both. i think it would be an
37 > >overkill having a separate "ebuild repository", it should rather
38 > >be kept central.
39 > >
40 > >probably a simple link like
41 > >
42 > >http://bugs.gentoo.org/buglist.cgi?component=Ebuilds
43 > >
44 > >(add your date constraints)
45 > >
46 > >would be sufficient if we just agreed on a standardized way how
47 > >ebuild submissions (and error reports) have to be made. this
48 > >could be done by "forcing" a formatted summary field. e.g. for
49 > >ebuild submissions:
50 > >
51 > >${P} ${DESCRIPTION}
52 > >
53 > >this would be suitable for most users (as gentoo mainly targets
54 > >developers/professionals and as the ebuild names are usually
55 > >self-explanatory). disclaimer: i do not know whether forcing
56 > >field formats is possible with bugzilla. a voting feature
57 > >would be nice too.
58 > >
59 > >rgds
60 > >
61 > >dan
62 > >
63 > >--
64 > > ...::: Daniel Mettler | http://www.numlock.ch :::....
65 > >
66 > >_______________________________________________
67 > >gentoo-dev mailing list
68 > >gentoo-dev@g.o
69 > >http://lists.gentoo.org/mailman/listinfo/gentoo-dev
70 >
71 > President
72 > www.cybrains.net
73 >
74 > "All things should be as simple as possible, but no simpler" -- Albert
75 > Einstein
76 >
77 > _______________________________________________
78 > gentoo-dev mailing list
79 > gentoo-dev@g.o
80 > http://lists.gentoo.org/mailman/listinfo/gentoo-dev