Re: did you check in 1.1 how the old browser now support the creation of new method cat

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Maintaining KPF (was Keeping released version image up to date (was did you...)

Stan Shepherd
Stéphane Ducasse wrote
Yes in an ideal world.
Now either we can script the bugreport to generate that list automatically
or we will not have the resources to do it.

Then I do not imagine somebody patient enough to read a log full of bug descriptions. :)
But may be I'm just too lazy.

Stef
On Dec 22, 2009, at 10:24 AM, Stan Shepherd wrote:

>
>
> Stéphane Ducasse wrote:
>>
>>
>>
>> The process we have in mind is that if the bug is **really** important
>> then it will be fixed in 1.1 and 1.0.
>> We did that in the past for Squeak 3.9.
>> Now normal improvements changes.... will not be retro-ported because we
>> simply cannot.
>> And you are right to report a bug it is important in the future that
>> people check if the bug is already fixed
>> in the current unstable else we will not be able to make process and we
>> will spend our time testing.
>>
>>
> It sounds like the periodic 1.0 releases need to include a known problems
> file, which would include all bugs fixed in 1.1 alpha but not planned to be
> retrofitted.
> And it's probably important to make clear that, if in doubt, we should log a
> bug and risk it being a duplicate. Because the people with a genius for
> finding bugs are new users, and they may not be able to tell whether or not
> it's the same bug.
>
> --
> View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support-the-creation-of-new-method-cat-tp4194364p4202687.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
Is it possible to add a new status in Google Code, of Closed-KPF-1.0?
Then Closed means it was fixed and retrofitted to 1.0. Closed-KPF-1.0 means fixed only in 1.1alpha.
Making the KPF list becomes trivial.
And it also captures the knowledge of whether the issue applied to 1.0 at the time of closing, rather than someone have to puzzle over it when making a release.
...Stan


Reply | Threaded
Open this post in threaded view
|

Re: Maintaining KPF (was Keeping released version image up to date (was did you...)

Stéphane Ducasse
Right now we have milestone1.0 and milestone1.1 for the fixes that are integrated in both
But indeed we could have a specific tags.

Stef

>>
>>
> Is it possible to add a new status in Google Code, of Closed-KPF-1.0?
> Then Closed means it was fixed and retrofitted to 1.0. Closed-KPF-1.0 means
> fixed only in 1.1alpha.
> Making the KPF list becomes trivial.
> And it also captures the knowledge of whether the issue applied to 1.0 at
> the time of closing, rather than someone have to puzzle over it when making
> a release.
> ...Stan
>
>
>
> --
> View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-support-the-creation-of-new-method-cat-tp4194364p4208144.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Maintaining KPF (was Keeping released version image up to date (was did you...)

Stan Shepherd
Stéphane Ducasse wrote
Right now we have milestone1.0 and milestone1.1 for the fixes that are integrated in both
But indeed we could have a specific tags.

Stef
>>
>>
> Is it possible to add a new status in Google Code, of Closed-KPF-1.0?
> Then Closed means it was fixed and retrofitted to 1.0. Closed-KPF-1.0 means
> fixed only in 1.1alpha.
> Making the KPF list becomes trivial.
> And it also captures the knowledge of whether the issue applied to 1.0 at
> the time of closing, rather than someone have to puzzle over it when making
> a release.
> ...Stan
>
So would:
http://code.google.com/p/pharo/issues/list?can=1&q=Type:Defect,ReportDefect++Milestone:1.1+Status:closed+++-Milestone:1.0&sort=type&colspec=ID+Type+Status+Summary+Milestone+Closed
Be the KPF IFF the type and status and milestone fields were maintained?

Reply | Threaded
Open this post in threaded view
|

Re: Maintaining KPF (was Keeping released version image up to date (was did you...)

Stéphane Ducasse
> So would:
> http://code.google.com/p/pharo/issues/list?can=1&q=Type:Defect,ReportDefect++Milestone:1.1+Status:closed+++-Milestone:1.0&sort=type&colspec=ID+Type+Status+Summary+Milestone+Closed
>
> Be the KPF IFF the type and status and milestone fields were maintained?


I'm not sure because what I saw was more 1.1 updates.
Normally we have
        milestone 1.0 for 1.0
        milestone 1.1 for 1.1
and when an issue should be back ported it gets the two tags.



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12