October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue tracker states

by Mariano Martinez Peck

THanks Marcus :) Maybe we should put that explanation somewhere? For example, in http://www.pharo-project.org/community/issue-tracking On Fri, Oct 28, 2011 at 5:59 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Thanks for the explanation. I was wondering... > > -- > View this message in context: > http://forum.world.st/Issue-tracker-states-tp3948297p3948360.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Oct. 28, 2011

Re: [Pharo-project] Issue tracker states

by Sean P. DeNigris

Thanks for the explanation. I was wondering... -- View this message in context: http://forum.world.st/Issue-tracker-states-tp3948297p3948360.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 28, 2011

[Pharo-project] Issue tracker states

by Marcus Denker

Hi, We started to improve the states defined in the tracker... this now has: FixToInclude = QA has verified that the fix worked, needs to be integrated FixReviewNeeded = Code is there, but a review is needed NoSourcesAvailable = fix proposed, but machine readable code missing Workneeded = Next action is defined but not yet completed NextActionNeeded = What is the next action? Accepted = Problem reproduced / Need acknowledged New = Nobody looked at this yet OnHold = We will come back later to this issue, no action possible now The issue tracker by default sorts the items to show the ones on top that have progressed the most: http://code.google.com/p/pharo/issues/list The idea is that the "FixToInclude" status should be integrated very quickly (within a day), later maybe even automatically. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 28, 2011

[Pharo-project] [update 1.3] #13319

by Marcus Denker

13319 ----- Issue 4934: Workspace Watch It menu entry action is broken http://code.google.com/p/pharo/issues/detail?id=4934 -- Marcus Denker -- http://marcusdenker.de

Oct. 28, 2011

[Pharo-project] [update 1.4] #14211

by Marcus Denker

14211 ----- Issue 4937: Squeaksource 3 place for gofer http://code.google.com/p/pharo/issues/detail?id=4937 Issue 4934: Workspace Watch It menu entry action is broken http://code.google.com/p/pharo/issues/detail?id=4934 Issue 4936: Temporarily switching to the non-interactive UIManager http://code.google.com/p/pharo/issues/detail?id=4936 -- Marcus Denker -- http://marcusdenker.de

Oct. 28, 2011

Re: [Pharo-project] Is RPackage dead?

by Lukas Renggli

In 2008 I wrote: There is a clean 1:1 mapping between categories/protocols and packages. If X is the package name, then ... 1. Category X is the core-package. 2. Category X-y is a sub-package y. 3. Protocol *X are extension methods. 4. Protocol *X-y is an extension to the y protocol. I see this as a way to move from the naming conventions to a first class package model. It is critical to have a browser that hides those naming conventions, while still keeping them (at the moment) for backward compatibility. Since there is no clean migration path, I vote for (A). When looking at Pharo today I don't see the current packaging system (or the lack thereof) as a major problem. The current infrastructure works reasonably well and does not hinder progress. What is really painful is that everything breaks with every release. Thus, what would be way more important is a module/namespace system so that we can load and run different versions of the same code without interfering. In the current state Pharo 1.3 is a dead end, because I will never be able to load my code into Pharo 1.4. Lukas On 28 October 2011 14:40, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Oct 28, 2011, at 1:20 PM, StÃ©phane Ducasse wrote: > >> Hi guys >> >> so what do we do with RPackage >> Â Â Â - (A) throw away 4 months or more of my work. I feel sorry for Nautilus and I could understand that benjmain gets really pissed off. >> Â Â Â but this means that we will stay with the old browsers. Sounds like a promising future. >> Â Â Â - (B) use it with a mapping one to one with category (and yes people will have to change the configurations). This is done. >> Â Â Â - (C) somebody takes three hours to look at what I did and think a bit but does not tell me that this is easy but propose >> Â Â Â a real plan to get towards a solution. >> >> Marcus, igor your wish to have labels (I added them to RPackage). I fixed SystemAnnouncement. >> Now without help it will not work (if you do not put energy on the table). Â I have a lot of wishes too and something else to do too. >> Because we have categories in additionâ¦ I discussed with Benjamin and we can fill up RPackageOrganizer with MCWorkingCopies but this >> means that we will have to match the complete system with subcategories ( >> Â Â Â Graphics-Core >> Â Â Â should match Graphics* >> >> So since it does not seem that we are pragmatic or that we want to make progress on this topic, I will do A and we will wait for concrete >> discussions. Apparently nobody care anyway. So this should not be important after all. >> >> Stef > > > Cool ... > > Ben > > > -- Lukas Renggli www.lukas-renggli.ch

Oct. 28, 2011

Re: [Pharo-project] Is RPackage dead?

by Benjamin

On Oct 28, 2011, at 1:20 PM, StÃ©phane Ducasse wrote: > Hi guys > > so what do we do with RPackage > - (A) throw away 4 months or more of my work. I feel sorry for Nautilus and I could understand that benjmain gets really pissed off. > but this means that we will stay with the old browsers. Sounds like a promising future. > - (B) use it with a mapping one to one with category (and yes people will have to change the configurations). This is done. > - (C) somebody takes three hours to look at what I did and think a bit but does not tell me that this is easy but propose > a real plan to get towards a solution. > > Marcus, igor your wish to have labels (I added them to RPackage). I fixed SystemAnnouncement. > Now without help it will not work (if you do not put energy on the table). I have a lot of wishes too and something else to do too. > Because we have categories in additionâ¦ I discussed with Benjamin and we can fill up RPackageOrganizer with MCWorkingCopies but this > means that we will have to match the complete system with subcategories ( > Graphics-Core > should match Graphics* > > So since it does not seem that we are pragmatic or that we want to make progress on this topic, I will do A and we will wait for concrete > discussions. Apparently nobody care anyway. So this should not be important after all. > > Stef Cool ... Ben

Oct. 28, 2011

[Pharo-project] Is RPackage dead?

by Torsten Bergmann

hi stef, I think I'm not the only one who didnt follow so close as you, Marcus, Igor, ... so please could you explain more in detail: - Problems mentioned with RPackage, Nautilus - why throw RPackage away and get stuck with the old browsers? I thought getting real packages was one of our most important tasks, so I could not understand you prefer solution A? Thanks T. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Oct. 28, 2011

[Pharo-project] Is RPackage dead?

by StÃ©phane Ducasse

Hi guys so what do we do with RPackage - (A) throw away 4 months or more of my work. I feel sorry for Nautilus and I could understand that benjmain gets really pissed off. but this means that we will stay with the old browsers. Sounds like a promising future. - (B) use it with a mapping one to one with category (and yes people will have to change the configurations). This is done. - (C) somebody takes three hours to look at what I did and think a bit but does not tell me that this is easy but propose a real plan to get towards a solution. Marcus, igor your wish to have labels (I added them to RPackage). I fixed SystemAnnouncement. Now without help it will not work (if you do not put energy on the table). I have a lot of wishes too and something else to do too. Because we have categories in additionâ¦ I discussed with Benjamin and we can fill up RPackageOrganizer with MCWorkingCopies but this means that we will have to match the complete system with subcategories ( Graphics-Core should match Graphics* So since it does not seem that we are pragmatic or that we want to make progress on this topic, I will do A and we will wait for concrete discussions. Apparently nobody care anyway. So this should not be important after all. Stef

Oct. 28, 2011

Re: [Pharo-project] Text for 1.3 announcement?

by Marcus Denker

On Oct 27, 2011, at 9:33 PM, Bernhard Pieber wrote: >> > What I always wanted to ask and did not dare until now: What is the meaning of a 1.3 tag? It *could* mean the following: > a) Those are the issues that are show stoppers before a release can be done. Yes, this is the meaning before the release is released. When a release gets close, we start to tag just the very important issues. With 1.2, we really managed to release when there where no issues tagged 1.2. With 1.3, there was just not enough energy left to do that. (yet, the issues left after the release where not of the kind of real show-stoppers, either.) We start with the next release at the point when a version gets frozen. Because lots of "trivial" changes accumulate in the tracker that can not be added to the to-be-stable version, yet not integrating will lead to a *huge* and unmanagable backlog. Thus even though 1.3 with 315 updates was released this week, there is a 1.4 with already 215 updates... (Or another number: 1.4 is 412 closed issues... the overall open issues is 427) But 1.3 is special, as we should have release it 4 months ago. > b) Those are known issues in 1.3. After the release, the issues tagged 1.3 are bugs found in 1.3 that are deemed to be fixed in 1.3. two cases are possible: 1) The bug is really something that lots of people will see, so we should fix it. 2) The reporter of the bug provides a perfect fix that can be harvested for 1.3 without any more work *and* where is is clear that it will not lead to more problems later *and* where the issue is deemed important If a company says "we use this in production" (e.g. Netstyle/CMSbox provides fixes of that sort, as an example) > At first I thought it meant a). When you removed the "release candidate" status from the 1.3 download page I started to doubt this. ;-) > My next assumption was it meant b). Hence my humble suggestion. Now it seems it must mean something completely different. No, it means both, depending on if the release is done or not. In a perfect world, the release is done without any open issues (by moving them to the next release, mostly). We missed that window for 1.3, mostly because of the problem of having two images (full and core). With the maintainers of the non-core packages only looking at released pharo versions, this was doomed to fail (to release both core and full at the same time). With 1.4, this is fixed. There is only one image, so we will just release 1.4 when a) all tests are green b) there are no issues tagged 1.4 Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 27, 2011