Closing bugzilla reports when harvesting?

[Ken Causey]

I could be misremembering but I thought it was decided that the release
team members would look for issues in Mantis marked 'resolved', harvest
any changesets there hopefully clearly marked as what should be
harvested, then mark the issue closed noting in what update number the
newly harvested bits appeared in the update stream.  Is that correct?

I ask because Todd Blanchard and I are going to try to make some
progress on I/O Stewards related issues and it seems like we could at
least finish up the issues already marked resolved.  We'll try to go
through all of them and confirm whether or not the changes are still
needed as of 3.9b-7032, and if so if the still apply, then get a mcz in
then io inbox and refer to it in the bug reports.  When you get a chance
please look at the issues marked Resolved on Mantis in the Network and
Files categories.  If they clearly point to an mcz in a
source.squeakfoundation.org then please look at them for harvesting.  If
not then just ignore them for now and check back as we will work on
getting them to that state.

Until I hear otherwise I'm going to work as if the intention is that
issues marked 'Resolved' are ready for harvesting and when the harvester
harvests them he will Close the issue.

Ken


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Thu, 2006-05-25 at 10:32 +0200, Marcus Denker wrote:
> Yes. Package maintainers should "resolve" the issue, then the image
> maintainers close them on inclusion.

Great, thanks.

> Good. And keep in mind that the next step for making IO a success
> would have been to harvest 2-3 trivial things and then merge with
> the image. If that would have been done in that fateful week of activity
> in January, everybody would have deemed the Networt package a success...
> ("I works, but people have not to much time").
>
> The real killer was over-commitment: "We need to at least rewrite  
> Networking
> completely before we can suggest it to be merged into the image". No.  
> One step
> at a time: Simple fix, release. repeat. When that's working, then  
> think about
> changing the world.
>
>        Marcus
>

I'm not sure I understand.  I will certainly admit that a lot of time
was lost in alpha to trying to decide what to do about
OldSocket/HttpSocket and to this day nothing has been done.  However the
following issues were marked Resolved in or before January yet have not
been harvested as far as I can tell:

http://bugs.impara.de/view.php?id=861

http://bugs.impara.de/view.php?id=2111

http://bugs.impara.de/view.php?id=2106

http://bugs.impara.de/view.php?id=411

That's not to say we couldn't have done more.  But we've certainly done
something and it doesn't look like the release team is noticing.

Ken


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Thu, 2006-05-25 at 16:38 +0200, Marcus Denker wrote:

> On 25.05.2006, at 16:20, Ken Causey wrote:
>
> >
> > following issues were marked Resolved in or before January yet have  
> > not
> > been harvested as far as I can tell:
> >
> > http://bugs.impara.de/view.php?id=861
> >
> > http://bugs.impara.de/view.php?id=2111
> >
> > http://bugs.impara.de/view.php?id=2106
> >
> > http://bugs.impara.de/view.php?id=411
> >
> > That's not to say we couldn't have done more.  But we've certainly  
> > done
> > something and it doesn't look like the release team is noticing.
> >
>
> We have, multiple times, asked for a mcz file to be added to the main
> image. We never got one. I once looked at the mcz files in the  
> networking
> projects, but I got confused as there where multiple ones and it was
> not clear which to take.
>
>        Marcus

Once again, that's why I asked if you guys were looking for Resolved
issues.  I've gone through most of those above and tried to clarify by
adding direct links to the MCZ where it was missing.  But in each case
the original Resolution comment mentioned an MCZ although sometimes it
was just the trailing bits minus the extension (like 'KLC.21') but still
given that the procedure has been to put them in the project inbox I
would have thought this would have been understood.  I will endeavour to
try to make this clearer in the resolution comments.

Also, please note there is no longer a Network Stewards team so although
there are still a few items in the Network inbox that you can harvest in
the future you will want to look in the IO inbox (for both Files and
Network items).

Ken


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Thu, 2006-05-25 at 17:33 +0200, Marcus Denker wrote:

> On 25.05.2006, at 17:28, Ken Causey wrote:
> > Once again, that's why I asked if you guys were looking for Resolved
> > issues.
>
> Yes, we do. But for networking, I had the impression that in that one  
> week,
> the networking team was building a big mcz. I don't know what made
> me think this, but for networking, I ingnored everything on mantis  
> and just
> waited for a big merged mcz package. I got to the conclusion that this
> is what the networking team wanted.
>
> So was that in the end a huge miss-understanding?

No, I don't think so, although I'm a little confused about your
reference in an earlier message to 'that fateful week of activity in
January'.  On April 3rd I sent a message to the v3dot9 list announcing
the availability of 3 MCZs that were the combined versions for 3
different categories (Network, NetworkTests and System) of all MCZs
produced to that date, please find the original message attached.

> (Please keep in mind that I have stopped harvesting with the 3.9b  
> release,
> so do not wait that I do something... I won't).

OK, I understand that.  I didn't mean to target you specifically with
this thread which is why I simply sent it to the v3dot9 list.  Perhaps
Stef will comment in time.

Thanks

>
>        marcus

I've looked through the old accumulated changes from the now merged
Network Stewards team and have combined those that affect the same
category.  Please feel free to harvest the following changesets from the
Network project on source.squeakfoundation.org:

http://source.squeakfoundation.org/network/System-gk.45.mcz

http://source.squeakfoundation.org/network/NetworkTests-gk.8.mcz

http://source.squeakfoundation.org/network/Network-KLC.27.mcz

Comparing a complete test before and after loading these results in no
apparent change in results (actually, I have trouble running it twice in
a row and getting the exact same results, but after running it many
times both before and after I don't believe there is any difference on
average).  Hopefully the included notes will be clear enough.  Any
suggestions for the future will be appreciated.

If I should use some other mechanism to submit changes, please let know.

Ken



_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Thu, 2006-05-25 at 17:38 +0200, Marcus Denker wrote:
> Hi again,
>
> Maybe for clearification: I think I got something wrong: The "resolved"
> items on mantis will be closed when merging the package into
> the image. But they don't trigger the merge itself, as the harverstes
> of the package might want to resolve multiple bugs without triggering
> inclusion of each and every step. So the team needs to trigger the
> harversters.

No, I did not understand that.  I assumed, and I think the rest of us
did as well, that the release team would periodically check the Mantis
for issues marked as Resolved and act appropriately and that for the
Steward Team marking the issue Resolved was the final step.  So you are
saying that not only should we mark the issue but we should also send a
notice that the issue is ready for harvesting to the v3dot9 list?

> I should stop to answer any harvesting related mails, I am not
> "in the flow" anymore, and I can't do anything anyway.

I understand, I'll be interested to hear from Stef.

>      Marcus



_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Thu, 2006-05-25 at 18:54 +0200, Marcus Denker wrote:
> The mail was send to v3.9@discuss... and silently disappeared/
>
> see archive:
>
> http://lists.squeakfoundation.org/pipermail/v3dot9/2006-April/date.html
>
>

Ah, shoot.  Well, I guess that explains it then.  Please consider this
notice that the following are ready for harvesting:

http://source.squeakfoundation.org/network/System-gk.45.mcz

http://source.squeakfoundation.org/network/Network-KLC.27.mcz

http://source.squeakfoundation.org/IO/Network-tb.28.mcz

http://source.squeakfoundation.org/IO/Network-tb.29.mcz

and please close the following Mantis entries:

http://bugs.impara.de/view.php?id=861

http://bugs.impara.de/view.php?id=2111

http://bugs.impara.de/view.php?id=2106

http://bugs.impara.de/view.php?id=411

http://bugs.impara.de/view.php?id=2454

http://bugs.impara.de/view.php?id=2107

Thank you v3.9 Release Team!

Ken



_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

> > http://source.squeakfoundation.org/IO/Network-tb.28.mcz
> >
> > http://source.squeakfoundation.org/IO/Network-tb.29.mcz
>
> hi ken
>
> I have the impression that only tb-29 is necessary.
> I will try and if you could check this would be good.
>
> Stef

No, in each case I had Todd start with a clean Squeak3.9b-7032 image,
and if you examine the changes for each one you will note that they are
separate and do not clash.  They change different classes and the
loading order should not matter.

Ken


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[tim Rowledge]

On 29-May-06, at 11:27 AM, Ken Causey wrote:

>>> http://source.squeakfoundation.org/IO/Network-tb.28.mcz
>>>
>>> http://source.squeakfoundation.org/IO/Network-tb.29.mcz
>>
>> hi ken
>>
>> I have the impression that only tb-29 is necessary.
>> I will try and if you could check this would be good.
>>
>> Stef
>
> No, in each case I had Todd start with a clean Squeak3.9b-7032 image,
> and if you examine the changes for each one you will note that they  
> are
> separate and do not clash.  They change different classes and the
> loading order should not matter.

That seems like a strange way to use MC, surely? Normally I would  
expect two .mcz of the same name but different increment to be  
sequential. To use them like this means having to merge rather than  
load.

tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim
A flash of light, a cloud of dust, and...  What was the question?


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Mon, 2006-05-29 at 14:48 -0700, tim Rowledge wrote:
> That seems like a strange way to use MC, surely? Normally I would  
> expect two .mcz of the same name but different increment to be  
> sequential. To use them like this means having to merge rather than  
> load.

That may well be.  I've now asked multiple times for a year or more to
have some sort of meeting between the release team and steward teams to
organize and standardize how we are to work together.  And actually the
one thing I've been told is to use the Merge button and not the Load
button.

I really don't know the right way to do this and have just tried to
manage as best as I could.

>
> tim
> --
> tim Rowledge; tim@...; http://www.rowledge.org/tim
> A flash of light, a cloud of dust, and...  What was the question?



_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io