| [equinox-dev] help |
----- Original Message -----
From:equinox-dev-request@xxxxxxxxxxx
To:equinox-dev@xxxxxxxxxxx
Subject:equinox-dev Digest, Vol 27, Issue 21
Date:07-07-12 02:25:36
Send equinox-dev mailing list submissions to
equinox-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
or, via email, send a message with subject or body 'help' to
equinox-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
equinox-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of equinox-dev digest..."
Today's Topics:
1. What to do with 3.3.1 candidate bugs and milestones
(Thomas Watson)
2. Re: What to do with 3.3.1 candidate bugs and milestones
(BJ Hargrave)
3. Re: What to do with 3.3.1 candidate bugs and milestones
(John Arthorne)
4. Re: Re: [prov] Deltas for delivering updates (Scott Lewis)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Jul 2007 12:42:41 -0500
From: Thomas Watson <tjwatson@xxxxxxxxxx>
Subject: [equinox-dev] What to do with 3.3.1 candidate bugs and
milestones
To: equinox-dev@xxxxxxxxxxx
Message-ID:
<OF52B95C23.399BE077-ON86257315.005EEA5C-86257315.00614424@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Each major release the same thing happens. We start fixing bugs in HEAD
for the next major release but find a few fixes that we would like to also
release into a maintenance release. Then we have to decide what to do
with the status of the original bug report which was used to release the
fix into HEAD. I have seen this handled in two ways.
1) Leave the bug open and mark the milestone to the next maintenance
release milestone (e.g. 3.3.1) and make a comment in the bug report
stating the fix was released to HEAD. If/When the fix gets approved and
released for the maintenance release then the bug is marked as fixed;
otherwise we make a note that the fix is not going to be included in the
maintenance release and the milestone is updated to major milestone the
fix was included and marked as fixed.
2) Resolve the bug report and mark the milestone appropriate for the next
major release (e.g. 3.4 M1) and open a separate bug with a proper
milestone for the maintenance release (e.g. 3.3.1).
For the past couple of releases the Equinox team has used option #1 but
this has a few drawbacks. First of all, it gives inaccurate search
results when querying bugzilla for the list of bug fixes for the next
release milestone because code was released into the milestone but the bug
is left open and marked for a maintenance stream. Also I find it
generally confusing that the bug status does not reflect the fixed state
of the bug until we can get approval and actually release the bug into the
maintenance stream.
The second approach has its advantages because it accurately reflects the
state of the bug for a particular stream and makes for more accurate
search results for fixed bugs and milestones. But there is a risk that
the open bug against the maintenance stream will not get approved for
release and then we would have to resolve the bug as wontfix (or
something). I'm not sure that is really a problem because at least the
reason why the fix is not in the maintenance stream is recorded. Another
disadvantage is that the bugs will look like duplicates which could cause
confusion.
What are other committers preferences? How is this handled on other
teams? Is there a standard Eclipse way to handle this?
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/listinfo/equinox-dev/attachments/20070711/6e8d4ed9/attachment.html
------------------------------
Message: 2
Date: Wed, 11 Jul 2007 13:54:18 -0400
From: BJ Hargrave <hargrave@xxxxxxxxxx>
Subject: Re: [equinox-dev] What to do with 3.3.1 candidate bugs and
milestones
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Message-ID:
<OF215CD209.02AE4915-ON85257315.00623580-85257315.00624E99@xxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"
Given bugzilla provides a "clone this bug" link, I think option #2 is the
best choice.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
office: +1 386 848 1781
mobile: +1 386 848 3788
Thomas Watson/Austin/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx
2007-07-11 13:42
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
equinox-dev@xxxxxxxxxxx
cc
Subject
[equinox-dev] What to do with 3.3.1 candidate bugs and milestones
Each major release the same thing happens. We start fixing bugs in HEAD
for the next major release but find a few fixes that we would like to also
release into a maintenance release. Then we have to decide what to do
with the status of the original bug report which was used to release the
fix into HEAD. I have seen this handled in two ways.
1) Leave the bug open and mark the milestone to the next maintenance
release milestone (e.g. 3.3.1) and make a comment in the bug report
stating the fix was released to HEAD. If/When the fix gets approved and
released for the maintenance release then the bug is marked as fixed;
otherwise we make a note that the fix is not going to be included in the
maintenance release and the milestone is updated to major milestone the
fix was included and marked as fixed.
2) Resolve the bug report and mark the milestone appropriate for the next
major release (e.g. 3.4 M1) and open a separate bug with a proper
milestone for the maintenance release (e.g. 3.3.1).
For the past couple of releases the Equinox team has used option #1 but
this has a few drawbacks. First of all, it gives inaccurate search
results when querying bugzilla for the list of bug fixes for the next
release milestone because code was released into the milestone but the bug
is left open and marked for a maintenance stream. Also I find it
generally confusing that the bug status does not reflect the fixed state
of the bug until we can get approval and actually release the bug into the
maintenance stream.
The second approach has its advantages because it accurately reflects the
state of the bug for a particular stream and makes for more accurate
search results for fixed bugs and milestones. But there is a risk that
the open bug against the maintenance stream will not get approved for
release and then we would have to resolve the bug as wontfix (or
something). I'm not sure that is really a problem because at least the
reason why the fix is not in the maintenance stream is recorded. Another
disadvantage is that the bugs will look like duplicates which could cause
confusion.
What are other committers preferences? How is this handled on other
teams? Is there a standard Eclipse way to handle this?
Tom
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
------------------------------
Message: 3
Date: Wed, 11 Jul 2007 14:19:43 -0400
From: John Arthorne <John_Arthorne@xxxxxxxxxx>
Subject: Re: [equinox-dev] What to do with 3.3.1 candidate bugs and
milestones
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Message-ID:
<OFE5EF1537.BC488DB3-ON85257315.006468D5-85257315.0064B0D7@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
I think option 2) is generally the way to go. On rare occasions I have
used option 1) if I release a fix into both streams at once, but if there
is any time difference between the fixes being released (and usually there
is), having a separate bug report per stream makes the most sense to me.
John
Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
07/11/2007 01:42 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
equinox-dev@xxxxxxxxxxx
cc
Subject
[equinox-dev] What to do with 3.3.1 candidate bugs and milestones
Each major release the same thing happens. We start fixing bugs in HEAD
for the next major release but find a few fixes that we would like to also
release into a maintenance release. Then we have to decide what to do
with the status of the original bug report which was used to release the
fix into HEAD. I have seen this handled in two ways.
1) Leave the bug open and mark the milestone to the next maintenance
release milestone (e.g. 3.3.1) and make a comment in the bug report
stating the fix was released to HEAD. If/When the fix gets approved and
released for the maintenance release then the bug is marked as fixed;
otherwise we make a note that the fix is not going to be included in the
maintenance release and the milestone is updated to major milestone the
fix was included and marked as fixed.
2) Resolve the bug report and mark the milestone appropriate for the next
major release (e.g. 3.4 M1) and open a separate bug with a proper
milestone for the maintenance release (e.g. 3.3.1).
For the past couple of releases the Equinox team has used option #1 but
this has a few drawbacks. First of all, it gives inaccurate search
results when querying bugzilla for the list of bug fixes for the next
release milestone because code was released into the milestone but the bug
is left open and marked for a maintenance stream. Also I find it
generally confusing that the bug status does not reflect the fixed state
of the bug until we can get approval and actually release the bug into the
maintenance stream.
The second approach has its advantages because it accurately reflects the
state of the bug for a particular stream and makes for more accurate
search results for fixed bugs and milestones. But there is a risk that
the open bug against the maintenance stream will not get approved for
release and then we would have to resolve the bug as wontfix (or
something). I'm not sure that is really a problem because at least the
reason why the fix is not in the maintenance stream is recorded. Another
disadvantage is that the bugs will look like duplicates which could cause
confusion.
What are other committers preferences? How is this handled on other
teams? Is there a standard Eclipse way to handle this?
Tom
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/listinfo/equinox-dev/attachments/20070711/d7b00503/attachment.html
------------------------------
Message: 4
Date: Wed, 11 Jul 2007 11:23:52 -0700
From: Scott Lewis <slewis@xxxxxxxxxxxxx>
Subject: Re: [equinox-dev] Re: [prov] Deltas for delivering updates
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Message-ID: <46952038.1080203@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
I agree with Pascal...I think it's best to keep delta logic out of ECF
if possible.
Identification info could be added to ECF's context (e.g. custom URL
with version info or a new adapter, an associated provider
implementation, etc), but this would at least imply having protocol
support for such meta data...which wouldn't be available for all
'typical' file transfer protocols...e.g. http/https/bittorrent, etc.
Scott
Pascal Rapicault wrote:
> As you correctly identified the separation of responsibility between ECF
> and the provisioning code is done as follow:
> - ECF is used to do the transports (e.g http, ftp, bittorrent). We
> leverage, its API, its transport pluggability (and eventually its ability
> to restart downloads).
> - The provisioning code (DownloadManager) is responsible to cause the
> download of all the requested artifacts using the artifact repos. It will
> be responsible for picking the best mirror (hopefully we can reuse what is
> in Maya) and also doing the parallelization.
>
>
>> Can/should delta handling be part of ECF - as a kind of smart
>>
> transport/download handling? Or is delta handling so important to
> provisioning that it should be part of provisioning?
> Given our usage of ECF, I don't think that ECF has enough context to be
> able to handle delta (it would not have the identification information that
> you are talking about). Therefore I think the ability to do delta depends
> on the repository in which the artifact is being mirrored to and from and
> it should be transparent for the download manager. Therefore with the
> current code I think the decision or not to use delta can be made in the
> MirrorRequest by checking the characteristics of the artifact repositories
> at hand, and the actual logic of getting the right delta could be left to
> the implementation of the repositories.
>
> It is also important to note that this code did not receive a lot of
> attention and anything could be changed.
>
> PaScaL
>
>
>
> "Liebig, Stefan "
> <Stefan.Liebig@co
> mpeople.de> To
> Sent by: <equinox-dev@xxxxxxxxxxx>
> equinox-dev-bounc cc
> es@xxxxxxxxxxx
> Subject
> [equinox-dev] Deltas for delivering
> 07/11/2007 04:49 updates
> AM
>
>
> Please respond to
> Equinox
> development
> mailing list
> <equinox-dev@ecli
> pse.org>
>
>
>
>
>
>
> I am currently investigating how the delta stuff (binary deltas) could fit
> into the ongoing provisioning work.
>
> When working with deltas there are certain constraints such as:
> - when requesting a delta for an artifact it is essential that the request
> contains an identification (version, md5, ..) of the artifact that is
> already available on the client, so that is possible to regenerate the new
> artifact from the old artifact and the delta.
> - the client should not rely on the fact that the server(s) can always
> respond with a delta. In some way the client needs to have some flexibility
> on handling the data (deltas, complete ?files?) which the server can
> respond.
>
> Currently provisioning uses ECF to handle the transport and download.
> Can/should delta handling be part of ECF - as a kind of smart
> transport/download handling? Or is delta handling so important to
> provisioning that it should be part of provisioning?
>
> Any thoughts?
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/listinfo/equinox-dev/attachments/20070711/7f32b69d/attachment.html
------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
End of equinox-dev Digest, Vol 27, Issue 21
*******************************************