On Sun, Nov 23, 2014 at 6:10 PM, Amar Takhar <a...@rtems.org> wrote: > On 2014-11-23 14:30 -0500, Gedare Bloom wrote: >> > Components themselves should be very general. 'RTEMS', 'Build', 'Testing', >> > 'BSP', 'CPU' etc. >> > With the 'arch' field, and ability to tag (e.g. on a bsp name), I think we only need "RTEMS" component to cover the sources of rtems.git. It may be nice if we can make 1:1 Components to RTEMS Project (and external support projects) Repostories.
>> OK, if we define some tags and scope them right, this can work. I >> don't like the idea of a free-text field though. Can tags be a >> drop-down list like the other fields? So we can define the set of >> tags? Either that, or put a link to the tag cloud or an organized tag >> list next to the keywords entry box, or similar, to give users (and >> forgetful developers) some guidance about what to put there. > > Keywords/tags are usually single word, space delimited lists it's meant for a > user to decide what applies or not. That's what a tag cloud is. > > We can modify the ticket page though to add a list of 'useful keywords' to > give > an idea of ones to use. > Ok > >> Using tags should be fine. > > I think we should have one for architecture. Default it to 'all' but anything > for a specific architecture should be set. Users will almost always fill this > out themselves so there is little work for us. > OK, and have a 'none' option too. >> We have two fields, Priority and Severity. Right now, each field has 5 >> choices. I'd like to reduce these to 3 each. >> >> Priority: High, Normal, Low. Priority encodes urgency. >> >> Severity: Blocker, Critical, Normal. Severity encodes deferrability. >> >> I would rename Severity->Criticality (leverage real-time jargon!), and >> change the values to "High, Normal, Low". High means the problem must >> be fixed in the affected versions. Normal means it should be fixed, >> but probably can be delayed. Low means it can be delayed without >> debate. >> >> The matrix of Priority x Criticality will have some nice meaning also. >> High-High corresponds to "get it done immediately", whereas Low-High >> means "get it done sometime before release", and so on. >> >> I don't think we need more than 3 levels in either category. > > Whoops, I forgot we had those two fields enabled. I'm used to having at least > one of them disabled. What you suggested is exactly how I would do it for > both > fields with both defaulting to 'normal'. I would suggest to add a 'minor' for > severity so we can let others know it is an item that can be moved trivially. > Whatever we call it, I just want 3 levels in each. There is no need for more. We could check what is in use already for these categories. > >> >> Third, we should fix Version to get rid of "unknown", "HEAD", and "". >> >> Tickets must be associated with a version, default to the current >> >> release series name, e.g. right now 4.11 (but soon 5.0). >> > >> > 'unknown' is being worked on and will go away. Removing 'HEAD' is good >> > but we >> > need to add a note to the ticket page saying 'choose version x.y.z for >> > 'devel/master'. >> > >> Yes. The default behavior also should be to choose the current release >> series name, e.g. right now 4.11, when 4.11 is released, the default >> milestone will be 5.0. > > FYI I just deleted the 'unknown' version Joel fixed those. > > I made the new default milestone 4.11.1 so any new tickets will default to > 4.11 > for version and 4.11.1 for milestone. > That is fine for pre-release. > 5 is really going to be it's own beast I don't think anyone will want to wait > for that to fix a 4.11 issue unless it requires large changes. > > >> As I said above, I'd prefer to do this in a way that limits the sprawl >> of tags. Also, tags appear to only work for single words, thus "RTEMS >> Source Builder" gets parsed into "RTEMS", "Source", "Builder". This >> should be addressed somewhere. > > Then you take away the exact reason tags and keywords exist. It's the user > that > decides what they are relevant to the issue they are having. Duplicates are > not > good and we can fix them however we should not limit what can be added. > > Most of our tickets are filed by the same set of people. It's OK if RTEMS > Source Builder because "RTEMS", "Source", "Builder" Because if someone wants > to > find all tickets related to source they'll find it. Same goes for RTEMS. If > they search for 'RTEMS Source Builder' they will find it as well. > > >> I see this also as an enhancement to the www component. My guess is >> most tasks can be framed as (proposed) enhancements. > > Here are tasks in Buildbot: > > http://trac.buildbot.net/query?status=accepted&status=assigned&status=new&status=reopened&type=task&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=version&order=priority > > A task is really just a task, it is a TODO of items that need to be completed > and nothing more. > > OK, I don't particularly care for it but maybe someone will use it effectively. (Perhaps this is a work-around for the lack of dependencies in Trac.) >> I still think this can be framed as either a defect or an enhancement >> to the infrastructure. The fact it is for "infrastructure" could be >> selected by the tag field? This example could be perhaps, defect in >> www component, with three tags: infrastructure, ftp, daemon > > No, it's a whole entire set of tickets that is logically separated from > everything else. > OK we'll see how it develops. > >> I'm mainly looking at how to keep the interface simple, especially for >> new users. For a user, the default behavior and drop-down lists should >> be easy to understand. > > The interface will still be simple. Hardly anyone will ever touch the ticket > type. I've never run into a case using trac where is confusing -- that > includes > project that have over a dozen ticket types. Anyone submitting a ticket will > know if they're going to use any of the other types. Anyone who doesn't know > what to do will leave it as the default. > > I'm more of a fan of trying things first and seeing what comes of it. We can > always remove the type, severities and other bits if they are unused or become > burdensome. Removing it before seeing how things go could end up removing > features that will help us out in the long run. > > > Amar. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
