From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=DATE_IN_PAST_06_12, DMARC_MISSING,INVALID_DATE,MAILING_LIST_MULTI,RDNS_NONE autolearn=no autolearn_force=no version=4.0.0 Received: from [66.56.80.159] (helo=att-56-80-159.localhost.localdomain ident=postfix) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15t49G-0008P7-00 for gentoo-dev@cvs.gentoo.org; Mon, 15 Oct 2001 03:35:02 -0600 Received: from dofty.zzn.com (localhost.localdomain [127.0.0.1]) by att-56-80-159.localhost.localdomain (Postfix) with ESMTP id 05AFB176E1 for ; Mon, 15 Oct 2001 05:35:24 -0400 (EDT) Message-ID: <3BCAADDC.3000402@dofty.zzn.com> From: Blue Lizard User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en-us MIME-Version: 1.0 To: gentoo-dev@cvs.gentoo.org Subject: Re: [gentoo-dev] What should be in place before 1.0 release References: <20011014163620.626d13c5.karltk@prosalg.no> <3BC9F783.6000300@dofty.zzn.com> <20011014233423.6d54a2be.karltk@prosalg.no> <1003137197.14313.8.camel@fry> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: gentoo-dev-admin@cvs.gentoo.org Errors-To: gentoo-dev-admin@cvs.gentoo.org X-BeenThere: gentoo-dev@cvs.gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@cvs.gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Mon Oct 15 03:36:02 2001 X-Original-Date: Mon, 15 Oct 2001 05:35:24 -0400 X-Archives-Salt: 217c4a59-32ae-449b-a3f3-dae6eeaf1121 X-Archives-Hash: e8c28b05944f304e6a22ecb24419a0d8 Mikael Hallendal wrote: > sön 2001-10-14 klockan 23.34 skrev Karl Trygve Kalleberg: > >>On Sun, 14 Oct 2001 16:37:23 -0400 >>Blue Lizard wrote: >> >> >>>bugzilla _could_ handle this, but while it is technically ready enough >>>our development team is in no way prepared to handle the influx of new >>>users that would find it a pain in the neck to use. >>> >>Then we find something that's easier to use. We really want this to >>further Gentoo development, not hamper it. I do not think our current >>system with sporadic mails to the gentoo-dev (and sometimes >>gentoo-ebuild!) list is good enough. >> > > I don't think that anyone thinks that gnome-dev a good solution for > bugreporting. (After all it should be a developer-list for > devel-discussions). > > I think that we should start using a bug-tracking system and that we > should start doing so soon. As I've said before, Bugzilla is really > powerful but can also be a large step for new users. However, this is > with the default-interface, we could do our own interface that's easier > to use. > > Someone also mentioned roundup (http://roundup.sourceforge.net/). I > tried to get it running on my Gentoo-machine but it didn't want to play. > Someone (and me) should give it another try. > > IMHO, we can choose either as long as it works. I also think that we > should use this system for our "todo"'s, in other words, start using the > bug-tracking system for what we currently uses Dev-wiki. > > I'm not sure about Roundup but bugzilla can also be used for handling > ebuilds (instead of gentoo-ebuild-list). > > Regards, > Mikael Hallendal > > Well, if you are making a new interface to bugzilla (or whatever backend is chosen), which seems preferable, then it is not a big deal to have separate interfaces (like different forms on a website) for a BR, UC, or FER. Bug report, usability correction, and feature enhancement request respectively. That way if someone not very intigrated with development or clueless about code thinks 'it would be cool if you could...' he need say little more. And it would be easier for triage, version control, that kind of thing. That is, easier from the POV of the person writing the report/request and easier for the developer(s) it concerns. So yes, I agree that writing a gentoo interface is a good idea. Roundup is pretty, but I fear that it might not suit our purposes very well. Still, learn from it. While implementing our own interfaces (kinda like real time triage), take from it that ease of gathering together all your active 'stuff' together. Page for users to look at bugs they've filed and their status, activity, etc. (think MyPage on ubid). Page for developers to see bugs assigned to them, if they are qa contact, if a bug has patch up for review and it falls in their 'sector' (component/area), new bugs that would be of interest (falls in area of specialty, contact, someone cc'ed them, etc.). Note that unlike mozilla's implementation, it is more contained in one system unit thingy. Like instead of being based on emails and cc's and chechking boxes or filling in...this is all totally together in my head but to put into words or code seems impossible. Think like the way it sorta (great, now the idea is evolving too far beyond the example) ... ya know. Like the way MandrakeExpert sorta kinda doesn't really work. Replace the expert select check boxes with a pulldown menu that updates with the selection of component and other aspect triaging attributes that minimize the required user knowledge background. This is so incoherent I'm just gonna stop. Look at this, not a single line break. It's how I think, must be why I'm always so confused ;P 5:34 AM? When did that happen? It's 2 isnt it? huh? -Blue (yeah, I might be the reason this ml turns moderated :p)