[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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=&quot;us-ascii&quot;

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=&quot;US-ASCII&quot;

Given bugzilla provides a &quot;clone this bug&quot; 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=&quot;us-ascii&quot;

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=&quot;iso-8859-1&quot;

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
>
>
>                                                                            
>              &quot;Liebig, Stefan &quot;                                             
>              <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
*******************************************



-------------------------------------------------------------------
MOTONBA篮球赛招募( http://d1.sina.com.cn/sina/limeng3/mail_zhuiyu/2007/mail_zhuiyu_20070709.html )

===================================================================
注册新浪2G免费邮箱( http://mail.sina.com.cn/chooseMode.html