Ticket #149 (closed planned_task: obsolete)

Opened 14 years ago

Last modified 13 years ago

PRO_CHANGE_PRIMITIVES_R0

Reported by: Astea Owned by: gogov
Priority: 3 Milestone: M03_PRE3
Component: PRO_LIB_ENTITIES Version: 2.0
Keywords: Cc:
Category: CORE Effort: 1
Importance: 18 Ticket_group:
Estimated Number of Hours: Add Hours to Ticket:
Billable?: Total Hours:
Analysis_owners: peko Design_owners:
Imp._owners: Test_owners:
Analysis_reviewers: orliin Changelog:
Design_reviewers: Imp._reviewers:
Test_reviewers: Analysis_score: 1
Design_score: 0 Imp._score: 0
Test_score: 0

Description

wiki page: PRO_CHANGE_PRIMITIVES_R0 - effort: 1d

Change History

comment:1 Changed 14 years ago by deyan

  • Category set to BASE
  • Design_score set to 0
  • Imp._score set to 0
  • Test_score set to 0
  • Analysis_score set to 0

Adding category

comment:2 Changed 14 years ago by peko

  • Importance changed from 0 to 18

comment:3 Changed 14 years ago by deyan

  • Category changed from BASE to CORE

correcting category

comment:4 Changed 14 years ago by peko

  • Owner changed from Astea to peko
  • Status changed from new to s1a_analysis_started
  • Analysis_owners set to peko

comment:5 Changed 14 years ago by peko

  • Status changed from s1a_analysis_started to s1b_analysis_finished

comment:6 Changed 14 years ago by orliin

  • Analysis_reviewers set to orliin
  • Analysis_score changed from 0 to 2
  • In the Overview: These include primitive changes and primitive operations about changes - in the Task requirements only operations are listed and types of primitive changes are not analysed.
  • In the Task requirements: create - which should create a change by class and an id - what is this class about; is this the id of the change being created, or an id of an object to attach to?
  • In the Task requirements: why is this set operation needed? Shouldn't a change be immutable in a sense that a change occurs and other things that happen are always new changes, not mutations of this change?
  • In the Task requirements: it is important to mention that UnmanagedChange-s should also have undo and redo functionality. It is just unique for each UnmanagedChange.


comment:7 Changed 14 years ago by orliin

  • Status changed from s1b_analysis_finished to new

comment:8 Changed 14 years ago by orliin

The comments are in the previous change..

comment:9 Changed 14 years ago by peko

  • Status changed from new to s1a_analysis_started

comment:10 Changed 14 years ago by peko

  • Status changed from s1a_analysis_started to s1b_analysis_finished

It appears I had not understood the primitives correctly. There is no change types in the primitives task. Composite change is a separate task.

comment:11 Changed 14 years ago by orliin

  • Status changed from s1b_analysis_finished to s1c_analysis_ok
  • Analysis_reviewers changed from orliin to orliin, orliin
  • Analysis_score changed from 2 to 3
  • In the Task requirements: create - which should create a change by class and an id - what is this class about; is this the id of the change being created, or an id of an object to attach to?
  • In the Task requirements: UnmanagedChange-s to be sure about what the scope of this should be, ask Milo :)

comment:12 Changed 14 years ago by gogov

  • Status changed from s1c_analysis_ok to new
  • Analysis_score changed from 2 to 1

changes change ProObjects, ProLists, etc.
changes do not change other changes!

the analysis score was inconsistent anyway

comment:13 Changed 14 years ago by gogov

  • Owner changed from peko to gogov
  • Status changed from new to s1a_analysis_started

comment:14 Changed 14 years ago by gogov

  • Status changed from s1a_analysis_started to s1b_analysis_finished

comment:15 Changed 13 years ago by deyan

  • Status changed from s1b_analysis_finished to new

Batch update from file query-1.csv

comment:16 Changed 13 years ago by deyan

  • Status changed from new to closed
  • Resolution set to obsolete

Batch update from file query-obsoleted.csv

Note: See TracTickets for help on using tickets.