SUnitToo(ls) in the Public Repository
Locked
SUnitToo(ls) in the Public Repository
 
|
While putting lots of stuff into a new image, I loaded SUnitToo, which
recommended SUnitToo(ls). So I connect to the public repository and find the following Published Items for SUnitToo(ls) (very-warped-50,tgriggs) Development 06/06/2007 (48.1,bobw) To Review 05/07/2007 (very-warped-49,michael) Broken 05/04/2007 (very-warped-48,tgriggs) Broken 04/18/2007 (37.2,mikeh) Development 02/23/2007 (37.1,mikeh) Development 02/22/2007 (48,mlq) Development 02/04/2007 (47,bpopov) Development 01/31/2007 Way too many publications are blessed as "Development", how am I to guess which one is "best" or "most reliable"? The interesting version numbers used by Travis shows that not all "Development" blessings are equal. Bobw published changes "To Review". Who is going to review and/or merge them? When? What's the fate of Mikeh's additions to the "old" 37-line of the package? Confused, s. |
Re: SUnitToo(ls) in the Public Repository
|
|
I totally agree. It is confusing. Here is what I loaded after trying
various configurations: SUnitToo (42,smichael) SUnitToo(ls) (48,mlq) Runar |
Re: SUnitToo(ls) in the Public Repository
|
|
I really like the code coverage tool that Michael Lucas Smith wrote,
so my setup is based around making this work. I use: SUnitToo (39,michael) SUnitToo(ls) (37.2,mikeh) SUnitToo(lsoverage) (1.1,michael) SunitToo(verage) (1.3,michael) When the code coverage was released I thought it was great, and should integrated permanently into the SUnitToo framework, but 2 days later new publishes of SUnitToo(ls) were published that broke it, and the development proceeded from there. There seems to have been no users of the coverage tool but me so for now that fork seems like a dead end. I haven't had any motivation to try to merge that fork back to the mainline. The current development seems to be supporting the new RB. Maybe Travis can comment on the best "stable release" for users of 7.5. Mike On Jun 28, 2007, at 6:48 AM, Runar Jordahl wrote: > I totally agree. It is confusing. Here is what I loaded after trying > various configurations: > > SUnitToo (42,smichael) > SUnitToo(ls) (48,mlq) > > Runar > |
Re: SUnitToo(ls) in the Public Repository
|
|
Travis will be back from vacation soon - though I'm not sure how
thrilled he'll be to see this thread. It's one of his pet peeves that anyone can come along and branch the code in such a way that it looks official. SUnitToo is /the/ project where that has happened to such a degree that it is a mess to follow. So just sit tight and hope he gets back soon with his 37.2 cents worth. Cheers, Michael Mike Hales wrote: > I really like the code coverage tool that Michael Lucas Smith wrote, > so my setup is based around making this work. > > I use: > > SUnitToo (39,michael) > SUnitToo(ls) (37.2,mikeh) > SUnitToo(lsoverage) (1.1,michael) > SunitToo(verage) (1.3,michael) > > When the code coverage was released I thought it was great, and should > integrated permanently into the SUnitToo framework, but 2 days later > new publishes of SUnitToo(ls) were published that broke it, and the > development proceeded from there. There seems to have been no users > of the coverage tool but me so for now that fork seems like a dead > end. I haven't had any motivation to try to merge that fork back to > the mainline. The current development seems to be supporting the new > RB. Maybe Travis can comment on the best "stable release" for users > of 7.5. > > Mike > > > On Jun 28, 2007, at 6:48 AM, Runar Jordahl wrote: > >> I totally agree. It is confusing. Here is what I loaded after trying >> various configurations: >> >> SUnitToo (42,smichael) >> SUnitToo(ls) (48,mlq) >> >> Runar >> > > |
Re: SUnitToo(ls) in the Public Repository
|
|
On Fri, 29 Jun 2007 09:01:46 +1000
Michael Lucas-Smith <[hidden email]> wrote: > Travis will be back from vacation soon - though I'm not sure how > thrilled he'll be to see this thread. It's one of his pet peeves that > anyone can come along and branch the code in such a way that it looks > official. SUnitToo is /the/ project where that has happened to such a > degree that it is a mess to follow. Maybe this could be fixed (simply?) by not using "Development" as much? Would a "Released" here and there do any damage? s. |
Re: SUnitToo(ls) in the Public Repository
|
|
On Jun 28, 2007, at 16:17, Stefan Schmiedl wrote:
The problem is that these "levels" mean something different to each person. I began using development more in response to comments from people that they were put off by my use of "work in progress". To warp a Knuthism: "There is no problem that can't be sufficiently more confusing by adding a layer of indirection." For me personally, the blessing thing is useless. They're names with lots of semantic overlap (e.g. is development not a form of work in progress?) for classifications that are amazing fungible. IMO, it's better to just put a real sentence in the publish comment that attempts to describe with real words what the developer's disposition is towards the publish. I don't pretend to do a very good job of this, but I'll recommit to doing better. That aside, if there are enough people on the list that can arrive at a concrete consensus as to what monikers to use when, so that less confusion is had, I'll try to follow those better. That is, you tell me how to decide how to label stuff better so stuff is more accessible, I'd simply love to follow those rules. Because I really do want the stuff to be accessible. -- Travis Griggs Objologist "It had better be a pretty good meeting, to be better than no meeting at all" - Boyd K Packer |
Re: SUnitToo(ls) in the Public Repository
|
|
On Sat, 30 Jun 2007 11:25:16 -0700
Travis Griggs <[hidden email]> wrote: > That aside, if there are enough people on the list that can arrive > at a concrete consensus as to what monikers to use when, so that > less confusion is had, I'll try to follow those better. The operative word here might very well be "when". Assuming I had done real work on a parcel (as opposed to small fixes) I'd be wary of using anything "better" than Development myself, until I got some feedback about quality of my work. OTOH there is not much choice "weaker" than Development: I'm done, so it's not "Work in Progress", it works for me, so it's not "Broken". "To Review" has an interesting psychological effect on me: it makes me feel like I'm back in school, anxiously awaiting the teacher's response. Can you change blessings after the fact? So, if you're going to be in "Broken" or "Work in Progress" for a while, bless the last "good" as "released" or so? Speaking from the point of a "library user", my choice would be much easier, if I saw, say, "48 released" somewhere in that list. Things get even more complicated, when the parcel in question is a real "public" parcel, without anybody who's really feeling responsible for keeping things integrated. > That is, you > tell me how to decide how to label stuff better so stuff is more > accessible, I'd simply love to follow those rules. Because I really > do want the stuff to be accessible. "I'd like to help you, but I can't." -- Mr. Incredible Store is a tool for, well, storing code. What's missing, is a workflow component detailing the next step, so that things are prompted to move on. Publish an update? Sure, I'll notify the other developers for the project for you, sir. Submitting a bug fix? I'll contact the original publisher of the release right away. These ideas obviously are not well thought out, they just kept popping up in my mind after putting "Getting Things Done" out as bathroom reading... s. |
Re: SUnitToo(ls) in the Public Repository
|
|
In reply to this post by Stefan Schmiedl
You can change blessings and add comments any time. |
Re: SUnitToo(ls) in the Public Repository
|
|
In reply to this post by Runar Jordahl
On Jun 28, 2007, at 5:48, Runar Jordahl wrote:
And I agree too. :) And accept some of the responsibility. Here's basically what's happened. We have three different forks of SUToo(ls) at this point. 1) The original stuff that held together and was pretty straight forward for awhile. Works with any supported version of the browser pretty good. If you want that original "stable" version, I'd load SUnitToo [38] SUnitToo(ls) [47] 2) At some point, there was excitement about adding yet-another-statistic. This was the whole "tests not run" thing. I won't call out names, because I see a couple of different names on the publish lists. This turned out to be a controversial topic. I've been unsupportive of it, but have otherwise laid low. One of my frustrations was that at some point, proponents of this decided to put it on the mainline version trunk (the integer one), but there are those of us that see this as feature pollution. So I've not "shepherded" SUToo as tightly as I could have, because I've been hoping a more elegant solution to that problem would make itself obvious to me. If you want to use that branch, you use the highest integer numbers of the packages, which right now are: SUnitToo [44] SUnitToo(ls) [48] 3) The 4xx series of the RB that I've been developing out in the open, abandons, pretty much prohibits, the technique the old tool used to wrap one code tool tab component with another. So this has to be rethought. Which I wanted to do, because under reflection, I came to the conclusion that the SUToo controls felt pretty hammered in. The "Very Warped" versions of SUnitToo(ls), were an original prototype of something to work in the modified RB. It's functional, but kind of cheesy. I will finish this version. I do not plan to support the 4th statistic with this version. I will at that time probably do a housecleaning on the core package. I'd like to simplify the pluggable testCaseClass stuff so that such efforts don't have to be made to keep it from making "dirty" methods. The prereq work I need to do here is making the status bar at the bottom of the RB pluggable in the same way that the main code tool section is. There are some other "abstractions" that I will probably back out of the core at that point too. -- Travis Griggs Objologist "You A students, you'll be back soon teaching here with me. You B students, you'll actually go on to be real engineers. You C students, you'll go into management and tell the A and B students what to do." - My Fluid Dynamics Professor whom I have yet to disprove |
Re: SUnitToo(ls) in the Public Repository
|
|
The problem seems to be that users of SUnitToo always load the most
recent version of every package. Prerequisites are set up without pointing to any specific version, so the image (or the user) will select the most recent one. Since SunitToo has active development going on, the most recent version might not be what you want. Isn't this story a great example of how a configuration (using a Bundle) can save the day? If we make a top bundle that loads stable releases, development can go on at any speed and any practice without affecting end-users. Runar |
Re: SUnitToo(ls) in the Public Repository
|
|
In reply to this post by Travis Griggs-3
> The problem is that these "levels" mean something different to each
person. I would take it further than that. In addition to meaning different things to different people, the blessings actually represent several different types of semantic categories, and if you replace a blessing from semantic category A with a blessing from semantic category B, then you have just lost the information from A that may still be relevant. Or you don't have any idea about category C. Here are some of the semantic categories I see: Code Quality Broken, Work In Progress, Tested Development Process Status To Review, Integration-Ready, Integrated, Ready To Merge, Merged, Tested, Distribution (who received these bits?) Development, Patch, Internal Release, Release Something can be Released, and then found to be Broken. But marking it Broken hides the fact that the bits went out to the user base. If different semantics were not mixed into the same field, that would be a good thing. Dave Travis Griggs wrote: > On Jun 28, 2007, at 16:17, Stefan Schmiedl wrote: > >> On Fri, 29 Jun 2007 09:01:46 +1000 >> Michael Lucas-Smith <[hidden email] >> <mailto:[hidden email]>> wrote: >> >>> Travis will be back from vacation soon - though I'm not sure how >>> thrilled he'll be to see this thread. It's one of his pet peeves that >>> anyone can come along and branch the code in such a way that it looks >>> official. SUnitToo is /the/ project where that has happened to such a >>> degree that it is a mess to follow. >> >> Maybe this could be fixed (simply?) by not using "Development" as much? >> Would a "Released" here and there do any damage? > > The problem is that these "levels" mean something different to each > person. I began using development more in response to comments from > people that they were put off by my use of "work in progress". To warp a > Knuthism: "There is no problem that can't be sufficiently more confusing > by adding a layer of indirection." > > For me personally, the blessing thing is useless. They're names with > lots of semantic overlap (e.g. is development not a form of work in > progress?) for classifications that are amazing fungible. IMO, it's > better to just put a real sentence in the publish comment that attempts > to describe with real words what the developer's disposition is towards > the publish. I don't pretend to do a very good job of this, but I'll > recommit to doing better. > > That aside, if there are enough people on the list that can arrive at a > concrete consensus as to what monikers to use when, so that less > confusion is had, I'll try to follow those better. That is, you tell me > how to decide how to label stuff better so stuff is more accessible, I'd > simply love to follow those rules. Because I really do want the stuff to > be accessible. > > -- > Travis Griggs > Objologist > "It had better be a pretty good meeting, to be better than no meeting > at all" - Boyd K Packer > > |
Re: SUnitToo(ls) in the Public Repository
|
|
In reply to this post by Travis Griggs-3
Dear Travis,
> For me personally, the blessing thing is useless. They're names with > lots of semantic overlap (e.g. is development not a form of work in > progress?) for classifications that are amazing fungible. IMO, it's > better to just put a real sentence in the publish comment that > attempts to describe with real words what the developer's disposition > is towards the publish. I don't pretend to do a very good job of this, > but I'll recommit to doing better. While I believe very strongly in writing blessing comments, I also use blessing levels and find them useful when parsing long lists of versions. I don't think there is much semantic overlap between e.g. 'broken' and 'tested' for example. > > That aside, if there are enough people on the list that can arrive at > a concrete consensus as to what monikers to use when, so that less > confusion is had, I'll try to follow those better. That is, you tell > me how to decide how to label stuff better so stuff is more > accessible, I'd simply love to follow those rules. Because I really do > want the stuff to be accessible. My usage, FWIW: broken: I know this does not work (i.e. in some sufficiently non-trivial way that you the reader need to know it too) halted (this one isn't in the standard list but should be): this ends a branch developing an idea that turned out not to be the way forward; unless the blessing level changes again, don't use it and don't develop from it without understanding why it was halted work in progress: not _known_ to be a sensible intermediate stage: probably saved because I was worried my latest change might break the image, thinking I might revert, just versioning-up before lunch, or some similar very 'track my coding'-specific reason. development: in practice, usually means "forgot to set blessing level". In my usage, _should_ mean that while the immediate XP test(s) that are driving development pass I haven't checked the full suite or similar, but in practice can sometimes mean "I forgot to set the blessing level." to review: development state or better, but either not fully tested or some other aspect needs thinking about patch: like halted but this branch is being used for a while and will only later be gazumped integration-ready: the multi-branch merge setting for the merge tool, which I never use for any other purpose and very rarely for that. The store code for this seems sloppy (#isReadyForIntegration: controls the tool but #blessingsForReadyForIntegration returns it in an array "... so this can be extended to use other blessings if desired." but noone calls it.) integrated, ready to merge: why is 'integration-ready' the merge tool input default but 'merged' its output default? Why indeed. I don't use 'integrated'. I would use 'ready to merge' for the merge tool input if I had any reason to create a version specifically for that purpose that did not require N-way merge. In practice, anything I'm merging usually already has a valid blessing level and there's no reason to reset it. merged: the merge tool's default publish setting. I also use 'merged' when I publish branches that were merged without using the merge tool or using it but deliberately avoiding its publish function to minimise new package creation. tested: passes the whole application test suite (possibly with minor exceptions listed in blessing comment) and/or has been reasonably exercised in the context of its whole application internal release: intra-project release. Function-wise, already thought ready to become 'release' but may need CM and similar checks or clean-up (e.g. make it load with no warnings) aligning of utilities, and/or approvals , etc. release: promises a level of robustness and usability; avers that enough work has been done for the releaser to have the right to believe the promise. HTH Yours faithfully Niall Ross |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |