launchpad developmentThe way that the Bug Linking LEP is mentioned initially confuses me. "This LEP contains information from the Bug Linking LEP": IOW, I don't need to read that LEP, but it overlaps a bit? "This LEP overlaps with the Bug Linking LEP, but is self-sufficient" ? "This LEP describes a self-sufficient subset of the functionality described in the Bug Linking LEP"?
Rationale
'will be able to declary' -> 'will be able to declare'
'Using the affect project or distro link will disclose private information' -> 'Using the "affects project or distro" link will disclose private information'?
"The links could explain their relationship, such as IS, LIKE, or DEPENDS.": This lack of specificity combined with a very broad possible scope makes me especially nervous. As I say later, my current belief is that generic "bug relationships" is an implementation choice. This LEP should be about Bug dependencies, and only mention dependencies and "meta" bugs, removing all mention to generic relationships and to the private project links except possibly in a new "potentially related features" section.
Stakeholders
You say that you copy OEM, hardware enablement, and so on from BugLinking. Don't bother IMO. Even if you separate out the private project goal from the bug dependency goal, as I suggest elsewhere, they still want *both* goals, right?
User stories
The inclusion of the BugLinking user stories is interesting. Those feel like a completely different use case that the dependency use case described here. Whether they are unified in implementation is in fact an implementation decision. Maybe the union of the two should be the subject of a separate (but linked) document/proposal.
Constraints and requirements
Must
"Ensure that relationships between bugs shouldn't (usually) alter the way that either of those bugs behave": ...right, except when they do. This seems like an empty assertion. If it is worth including, I think it needs more specificity. Maybe your thoughts can go in the "Must not" section?
'Provide the ability to mark a bug as a "meta bug" of two or more other bugs.': the difference between this and a standard dependency dependency relationship is pretty subtle. In other systems, I've seen this modeled as a standard dependency relationship with a new status that means "Fix released when the dependencies are fix released". Actually, you say, "mark a bug" not "mark a relationship" so maybe nevermind....
For the "meta bug" one: I suggest that you explicitly specify that the system will be responsible for automatically resolving "meta" bugs. Will it also be responsible for unresolving--in fact, will the status for the meta bug be managed entirely by the system? Maybe this gets into too much specificity for a LEP, but I think automation should be explicitly mentioned in the LEP, and perhaps your proposed policy described in a linked document.
I think we're missing a "must": a way for the users to understand what must happen for a bug to become unblocked (or for the "meta" relationship or status, what must happen for a bug to be resolved). The graph you describe in "nice to have" is one possible mechanism, but we need *a* mechanism.
Nice to have
"Bug duplication described as a Bug Relationship." What does this mean?
Subfeatures
Oh! BugLinking is a subset of this one? Oh.
/me goes away to finally go read that LEP. /me comes back.
It seems almost like we have two unrelated LEPs here, and one implementation proposal and/or LEP.
Unrelated LEPs:
- Project group linking. - Dependency linking.
LEP and/or implementation proposal:
- Project group links and dependency links should be...similar.
The "similar" part determines, at least in part, whether this is a third LEP or an implementation proposal. If the user will have no real idea that these two LEPs use the same internal linking mechanism, then this is a implementation proposal, and entirely within the realm of the TA and devs. If instead users will be able to somehow make generic typed/annotated relationships themselves, then that's a LEP. I doubt its a LEP. OTOH, on the bug linking LEP, jml asks sinzui "Have you seen mpt's thoughts on bug linking / dependencies?". Where can we find them? Have you considered them? Maybe they can be extrapolated into a user-facing LEP somehow?
Let's say it's an implementation proposal, as I suspect. To go further with this, I think that Lean would tell us to implement bug dependencies *or* project group links, without slowing down to try and design a system friendly to both. When/if we get to the other LEP, we refactor then. Maybe that's when we build a real bug relationship tool.
Success/Thoughts
You don't mention the private-project-related goals of this at all. This adds to my concern about how these are linked in the LEP.
The success definition so far is too unspecific and perhaps also too far-reaching.
Perhaps it can be "OEM, Hardware enablement, Ubuntu, and Launchpad (the four identified stakeholders) each mark bug dependencies multiple times a week"? Or, "a review of bug comments for newly filed bugs for the four identified stakeholder groups show that bug dependencies are now being modeled in the data rather than in the comments"? "the percentage of bugs mentioned in comments that are not duplicates or related via a dependency chain drops to below half of the value from before we implement dependency chains, indicating significant uptake of this feature assuming other factors remain approximately stable"?
The fact that you mention replacing blueprints as a non-goal, but then kind of a rejected success goal, makes me think that we need to explore this. Maybe we need to in fact say explicitly that a goal of this LEP *is* to replace blueprints for [use case 1] and [use case 2] and [use case 3]. We are not trying to replace the use of blueprints for [use case 4]. Once we admit this--and it really sounds like we should from the subtext that I read--we can maybe get better at identifying some goals and success descriptions.
