Spoon March 2008

spoon@lists.squeakfoundation.org

1 participants
2 discussions

Naiad use case: issue tracking
by Matthew Fulmer 26 Mar '08

26 Mar '08

Based on my previous comment, I realized it seems that bug-fixes will not look like they do today in a Naiad context. Due to the non-use of files in naiad, it seems that an external issue tracker may not even be an option! Therefore, we should consider this in the design. How would issue-tracking work in a system like naiad? First, we should define what kind of issues we are interested in: 1. Bug reports (manual and/or automatic): an end-user finds a problem, fills out a form with relevant info, and may or may not follow-up to it. Walkbacks could make this semi-automatic. There is already a button somewhere in squeak to email a bug report to the mailing list, but I don't remember where. 2. Code Requests: A developer encounters code exhibiting ugliness, non-existence, or general lameness, and submits an issue that said code should be cleaned up. 3. Meta-issues: Issues to keep track of other issues, such as Mother-of-X issues, issues to be included in a release, relationships/dependencies between issues, duplicate reports, etc. One way this could work is that an issue would be an item/module in the history database, which would hold comments somehow. As the issue marches toward completion, it would sprout dependencies on new code modules which would be loaded when someone syncs with the issue, the idea being that these dependencies resolve the issue when loaded. If the issue is not-trivial, multiple-passes at a fix would be made. This would use whatever mechanism naiad already has in place to keep track of old versions of stuff. I don't know if naiad already supports relationships among entities, but I suspect it does. Issues could: - DEPEND on code modules, other issues, or anything - DUPLICATE other issues, meaning that all comments/submissions on one issue should be redirected to another, probably just by convention - RELATE to other entities. A way to mark relationships for the benefit of future readers. No special meaning in code It is not clear to me, being unfamiliar with naiad, whether this scheme is necessary, overkill, or not already present. It is also not clear whether this would be better-handled by something already present but not naiad-aware, like Mantis or Gjallar. I bring it up because all the issue trackers I have used expect objects/patches to be files, which does not match with naiad at all, and so are of lesser, if any, utility to naiad users. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

1 0

Kettle use case: method alternatives
by Matthew Fulmer 25 Mar '08

25 Mar '08

Here is a use case that I think would be very useful when porting code, especially small bug fixes, across forks. I have wanted to add this to DeltaStreams. You fix a bug in squeak.org, and it involves changing the #foo method from: foo ^ 1 to: foo self ensureWhizbangInitialized. ^ 1 Now, you realize that this bug needs to be fixed in Croquet as well, where foo looks like: foo ^ 2 So, you try loading the bug fix into Croquet, and, naturally, it brings up a conflict that you must resolve, since the expected previous method does not match the actual installed method. You resolve it like: foo self ensureWhizbangInitialized. ^ 2 and forget about it, because the system has recorded this as an alternative, and whoever fetches the bug fix in the future will receive both versions and automatically choose the one that best matches their fork and has the same previous method that you had when you resolved the conflict. I haven't really thought about how this would work if you needed to specify alternative groups of methods, again dependent on which fork you load code into. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Spoon March 2008