Re: 4.15 maintenance branch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 4.15 maintenance branch

Andrey Loskutov
Thanks Dani,
 
I want to clarify the rules once again, may be I will put it somewhere in the wiki once we agreed.
 
So in order to push commit to R4_XX_maintenance branch, one must follow RC2 criteria, which are:
 
"All fixes submitted must have a project lead or PMC vote on the bug report, and the fix must be reviewed by an additional committer (any committer other than the one who made the fix). A positive review from a project lead or PMC member means implicit approval and no vote is needed on the bug report."
 
I read it this way:
 
1) On gerrit with backported patch ask for the "+1" review from or from PL/PMC or from a committer that was not the original patch owner.
The committer who backports the patch but is not the owner of the original patch, is also allowed to vote with "+1".
2) If the "+1" reviewer on gerrit is not PL/PMC, ask them in a comment on original bug for an explicit "+1" for backporting.
3) If 1) and 2) are successfully done, and tests are OK, gerrit can be merged.
4) API changes or new features backported require additionally explicit PMC approval.
 
Is this above right so far?
 
The only question regarding point 2) I have is: do we really need PL/PMC to be involved, even if we don't build anything from the sources and in theory nobody is at risk?
The PL/PMC vote is worrying me, looking on the number of JDT core fixes I've backported so far on 4.12 branch and the known lack of resources in JDT team.
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Freitag, 28. Februar 2020 um 14:54 Uhr
Von: "Daniel Megert" <[hidden email]>
An: "Eclipse platform release engineering list." <[hidden email]>, "Eclipse platform general developers list." <[hidden email]>
Betreff: Re: [platform-releng-dev] 4.15 maintenance branch
Hi Andrey

Thanks for bringing this up.

Since the release train moved to a quarterly release cycle there was zero interest to contribute to the maintenance branches that get created when moving to the next release. It was only used by IBM and fed with backports by IBMers (maybe with some exceptions that I can't remember right now). Right from the beginning IBM wanted to make those fixes available for everyone and not keep them in a private branch. It would be great if other people use the maintenance branches (also old ones) to backport critical fixes, or fixes that are important to their work/product/company.

Given that the code is merged after RC2, the same rules must be followed as for RC2 in https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_15.php. This also means: no API changes or feature work without PMC approval.

The Platform Releng team will not spend resources to do maintenance builds. However, anyone can use the source and build it but must not expect the Platform Releng team to hold hands.

So, welcome Andrey!
Dani



From:        Andrey Loskutov <[hidden email]>
To:        "Eclipse platform release engineering list." <[hidden email]>, "Eclipse platform general developers list." <[hidden email]>
Date:        27.02.2020 21:03
Subject:        [EXTERNAL] [platform-releng-dev] 4.15 maintenance branch
Sent by:        [hidden email]



Hi all,

since we've started with Eclipse quarterly release cadence we've
basically stopped development on maintenance branch. I saw that few
commits were done here and there, but I didn't found any strategy /
guidance.

In short, I maintain private 4.12 SDK branch with lot of backported
patches from master. I do this for our product, and I plan to start
another maintenance branch for 4.15 soon.

This time I believe it would make sense to not maintain my own private
branch, but just push backported patches we need to the "official"
R4_15_maintenance branch.

What would be the "right" way to do so? Do I need any approval from
component leads, do I need extra bugs opened to backport regression
fixes, any "+1" from other developers? Or can I just push, run gerrit
build, and if it is green, merge? Since no one seem to work on
maintenance branches anyway, this should be not a problem for anyone?

Another question would be if we could produce some regular SDK snapshot
builds from that branch, and if there are resources & interest for this?
I personally don't need that build, we build SDK locally, but it could
be something people are searching for.

I'm asking here because I believe it makes sense to give results of my
(paid) maintenance work back to community, and it is really sad to see
people searching for some fixes on a "known good" SDK version but seeing
only the way to get a new major SDK version with new unknown regressions
instead.

Please note, I do not plan to maintain backports branch for every major
SDK release, I have only resources (and plan) to do this for *some*
releases.

So there are basically two questions:

1) What are the rules for backporting patches to maintenance branch?
2) Any interest in producing SDK builds from this branch?

--
Kind regards,
Andrey Loskutov


https://www.eclipse.org/user/aloskutov
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------
_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-releng-dev


_______________________________________________ platform-releng-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev

_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-releng-dev
Reply | Threaded
Open this post in threaded view
|

Re: 4.15 maintenance branch

Daniel Megert
Hi Andrey

> Is this above right so far?
Yes :-)

> The only question regarding point 2) I have is: do we really need PL/PMC to be involved,
Yes, definitely. First, it makes absolutely no sense to use lowered rules than for RC2. Second, "we don't build anything from the sources" is wrong. IBM does, and other people/companies might do as well.

If you get into a blocker with JDT Core fixes, just ping me.

Dani



From:        "Andrey Loskutov" <[hidden email]>
To:        [hidden email]
Cc:        "Eclipse platform release engineering list." <[hidden email]>
Date:        28.02.2020 18:05
Subject:        [EXTERNAL] Re: [platform-releng-dev] 4.15 maintenance branch
Sent by:        [hidden email]




Thanks Dani,
 
I want to clarify the rules once again, may be I will put it somewhere in the wiki once we agreed.
 
So in order to push commit to R4_XX_maintenance branch, one must follow RC2 criteria, which are:
 
"All fixes submitted must have a project lead or PMC vote on the bug report, and the fix must be reviewed by an additional committer (any committer other than the one who made the fix). A positive review from a project lead or PMC member means implicit approval and no vote is needed on the bug report."
 
I read it this way:
 
1) On gerrit with backported patch ask for the "+1" review from or from PL/PMC or from a committer that was not the original patch owner.
The committer who backports the patch but is not the owner of the original patch, is also allowed to vote with "+1".
2) If the "+1" reviewer on gerrit is not PL/PMC, ask them in a comment on original bug for an explicit "+1" for backporting.
3) If 1) and 2) are successfully done, and tests are OK, gerrit can be merged.
4) API changes or new features backported require additionally explicit PMC approval.
 
Is this above right so far?
 
The only question regarding point 2) I have is: do we really need PL/PMC to be involved, even if we don't build anything from the sources and in theory nobody is at risk?
The PL/PMC vote is worrying me, looking on the number of JDT core fixes I've backported so far on 4.12 branch and the known lack of resources in JDT team.
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Freitag, 28. Februar 2020 um 14:54 Uhr
Von:
"Daniel Megert" <[hidden email]>
An:
"Eclipse platform release engineering list." <[hidden email]>, "Eclipse platform general developers list." <[hidden email]>
Betreff:
Re: [platform-releng-dev] 4.15 maintenance branch

Hi Andrey

Thanks for bringing this up.


Since the release train moved to a quarterly release cycle there was zero interest to contribute to the maintenance branches that get created when moving to the next release. It was only used by IBM and fed with backports by IBMers (maybe with some exceptions that I can't remember right now). Right from the beginning IBM wanted to make those fixes available for everyone and not keep them in a private branch. It would be great if other people use the maintenance branches (also old ones) to backport critical fixes, or fixes that are important to their work/product/company.


Given that the code is merged after RC2, the same rules must be followed as for RC2 in
https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_15.php. This also means: no API changes or feature work without PMC approval.

The Platform Releng team will not spend resources to do maintenance builds. However, anyone can use the source and build it but must not expect the Platform Releng team to hold hands.


So, welcome Andrey!
Dani




From:        
Andrey Loskutov <[hidden email]>
To:        
"Eclipse platform release engineering list." <[hidden email]>, "Eclipse platform general developers list." <[hidden email]>
Date:        
27.02.2020 21:03
Subject:        
[EXTERNAL] [platform-releng-dev] 4.15 maintenance branch
Sent by:        
[hidden email]



Hi all,

since we've started with Eclipse quarterly release cadence we've
basically stopped development on maintenance branch. I saw that few
commits were done here and there, but I didn't found any strategy /
guidance.

In short, I maintain private 4.12 SDK branch with lot of backported
patches from master. I do this for our product, and I plan to start
another maintenance branch for 4.15 soon.

This time I believe it would make sense to not maintain my own private
branch, but just push backported patches we need to the "official"
R4_15_maintenance branch.

What would be the "right" way to do so? Do I need any approval from
component leads, do I need extra bugs opened to backport regression
fixes, any "+1" from other developers? Or can I just push, run gerrit
build, and if it is green, merge? Since no one seem to work on
maintenance branches anyway, this should be not a problem for anyone?

Another question would be if we could produce some regular SDK snapshot
builds from that branch, and if there are resources & interest for this?
I personally don't need that build, we build SDK locally, but it could
be something people are searching for.

I'm asking here because I believe it makes sense to give results of my
(paid) maintenance work back to community, and it is really sad to see
people searching for some fixes on a "known good" SDK version but seeing
only the way to get a new major SDK version with new unknown regressions
instead.

Please note, I do not plan to maintain backports branch for every major
SDK release, I have only resources (and plan) to do this for *some*
releases.

So there are basically two questions:

1) What are the rules for backporting patches to maintenance branch?
2) Any interest in producing SDK builds from this branch?

--
Kind regards,
Andrey Loskutov


https://www.eclipse.org/user/aloskutov
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------
_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-releng-dev


_______________________________________________ platform-releng-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-releng-dev_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-releng-dev



_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-releng-dev
Reply | Threaded
Open this post in threaded view
|

Re: 4.15 maintenance branch

Andrey Loskutov
Dani,
 
thank you for feedback, I've put the result on the wiki: https://wiki.eclipse.org/Platform/How_to_Contribute#Contributing_to_maintenance_release_branches
 
I've pushed already first patches to gerrit for R4_15_maintenance, will ask for +1 by owners soon.
 
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Freitag, 28. Februar 2020 um 19:02 Uhr
Von: "Daniel Megert" <[hidden email]>
An: "Eclipse platform release engineering list." <[hidden email]>
Cc: [hidden email]
Betreff: Re: [platform-releng-dev] 4.15 maintenance branch
Hi Andrey

> Is this above right so far?
Yes :-)

> The only question regarding point 2) I have is: do we really need PL/PMC to be involved,
Yes, definitely. First, it makes absolutely no sense to use lowered rules than for RC2. Second, "we don't build anything from the sources" is wrong. IBM does, and other people/companies might do as well.

If you get into a blocker with JDT Core fixes, just ping me.

Dani



From:        "Andrey Loskutov" <[hidden email]>
To:        [hidden email]
Cc:        "Eclipse platform release engineering list." <[hidden email]>
Date:        28.02.2020 18:05
Subject:        [EXTERNAL] Re: [platform-releng-dev] 4.15 maintenance branch
Sent by:        [hidden email]



Thanks Dani,
 
I want to clarify the rules once again, may be I will put it somewhere in the wiki once we agreed.
 
So in order to push commit to R4_XX_maintenance branch, one must follow RC2 criteria, which are:
 
"All fixes submitted must have a project lead or PMC vote on the bug report, and the fix must be reviewed by an additional committer (any committer other than the one who made the fix). A positive review from a project lead or PMC member means implicit approval and no vote is needed on the bug report."
 
I read it this way:
 
1) On gerrit with backported patch ask for the "+1" review from or from PL/PMC or from a committer that was not the original patch owner.
The committer who backports the patch but is not the owner of the original patch, is also allowed to vote with "+1".
2) If the "+1" reviewer on gerrit is not PL/PMC, ask them in a comment on original bug for an explicit "+1" for backporting.
3) If 1) and 2) are successfully done, and tests are OK, gerrit can be merged.
4) API changes or new features backported require additionally explicit PMC approval.
 
Is this above right so far?
 
The only question regarding point 2) I have is: do we really need PL/PMC to be involved, even if we don't build anything from the sources and in theory nobody is at risk?
The PL/PMC vote is worrying me, looking on the number of JDT core fixes I've backported so far on 4.12 branch and the known lack of resources in JDT team.
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих


https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Freitag, 28. Februar 2020 um 14:54 Uhr
Von: "Daniel Megert" <[hidden email]>
An: "Eclipse platform release engineering list." <[hidden email]>, "Eclipse platform general developers list." <[hidden email]>
Betreff: Re: [platform-releng-dev] 4.15 maintenance branch

Hi Andrey

Thanks for bringing this up.

Since the release train moved to a quarterly release cycle there was zero interest to contribute to the maintenance branches that get created when moving to the next release. It was only used by IBM and fed with backports by IBMers (maybe with some exceptions that I can't remember right now). Right from the beginning IBM wanted to make those fixes available for everyone and not keep them in a private branch. It would be great if other people use the maintenance branches (also old ones) to backport critical fixes, or fixes that are important to their work/product/company.

Given that the code is merged after RC2, the same rules must be followed as for RC2 in https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_15.php. This also means: no API changes or feature work without PMC approval.

The Platform Releng team will not spend resources to do maintenance builds. However, anyone can use the source and build it but must not expect the Platform Releng team to hold hands.

So, welcome Andrey!
Dani




From:        Andrey Loskutov <[hidden email]>
To:        "Eclipse platform release engineering list." <[hidden email]>, "Eclipse platform general developers list." <[hidden email]>
Date:        27.02.2020 21:03
Subject:        [EXTERNAL] [platform-releng-dev] 4.15 maintenance branch
Sent by:        [hidden email]



Hi all,

since we've started with Eclipse quarterly release cadence we've
basically stopped development on maintenance branch. I saw that few
commits were done here and there, but I didn't found any strategy /
guidance.

In short, I maintain private 4.12 SDK branch with lot of backported
patches from master. I do this for our product, and I plan to start
another maintenance branch for 4.15 soon.

This time I believe it would make sense to not maintain my own private
branch, but just push backported patches we need to the "official"
R4_15_maintenance branch.

What would be the "right" way to do so? Do I need any approval from
component leads, do I need extra bugs opened to backport regression
fixes, any "+1" from other developers? Or can I just push, run gerrit
build, and if it is green, merge? Since no one seem to work on
maintenance branches anyway, this should be not a problem for anyone?

Another question would be if we could produce some regular SDK snapshot
builds from that branch, and if there are resources & interest for this?
I personally don't need that build, we build SDK locally, but it could
be something people are searching for.

I'm asking here because I believe it makes sense to give results of my
(paid) maintenance work back to community, and it is really sad to see
people searching for some fixes on a "known good" SDK version but seeing
only the way to get a new major SDK version with new unknown regressions
instead.

Please note, I do not plan to maintain backports branch for every major
SDK release, I have only resources (and plan) to do this for *some*
releases.

So there are basically two questions:

1) What are the rules for backporting patches to maintenance branch?
2) Any interest in producing SDK builds from this branch?

--
Kind regards,
Andrey Loskutov


https://www.eclipse.org/user/aloskutov
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------
_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-releng-dev


_______________________________________________ platform-releng-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-releng-dev


_______________________________________________ platform-releng-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev

_______________________________________________
platform-releng-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev
Reply | Threaded
Open this post in threaded view
|

Re: 4.15 maintenance branch

Sarika Sinha
Few more points in wiki will be good to have:
1. Bug should display correct target milestone. ex: a bug fix back ported to 4_15_maintenance will have target milestone as 4.15+.
2. Suppose a bug in 4.16 development time is  back ported to 4_14_maintenance, target milestone should 4.14+ and it should be back ported to 4_15_maintenance also.
 
Thanks & Regards,
Sarika
 
 
----- Original message -----
From: "Andrey Loskutov" <[hidden email]>
Sent by: [hidden email]
To: [hidden email]
Cc:
Subject: [EXTERNAL] Re: [platform-releng-dev] 4.15 maintenance branch
Date: Thu, Mar 19, 2020 3:04 AM
 
Dani,
 
thank you for feedback, I've put the result on the wiki: https://wiki.eclipse.org/Platform/How_to_Contribute#Contributing_to_maintenance_release_branches
 
I've pushed already first patches to gerrit for R4_15_maintenance, will ask for +1 by owners soon.
 
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Freitag, 28. Februar 2020 um 19:02 Uhr
Von: "Daniel Megert" <[hidden email]>
An: "Eclipse platform release engineering list." <[hidden email]>
Cc: [hidden email]
Betreff: Re: [platform-releng-dev] 4.15 maintenance branch
Hi Andrey

> Is this above right so far?
Yes :-)

> The only question regarding point 2) I have is: do we really need PL/PMC to be involved,
Yes, definitely. First, it makes absolutely no sense to use lowered rules than for RC2. Second, "we don't build anything from the sources" is wrong. IBM does, and other people/companies might do as well.

If you get into a blocker with JDT Core fixes, just ping me.

Dani



From:        "Andrey Loskutov" <[hidden email]>
To:        [hidden email]
Cc:        "Eclipse platform release engineering list." <[hidden email]>
Date:        28.02.2020 18:05
Subject:        [EXTERNAL] Re: [platform-releng-dev] 4.15 maintenance branch
Sent by:        [hidden email]



Thanks Dani,
 
I want to clarify the rules once again, may be I will put it somewhere in the wiki once we agreed.
 
So in order to push commit to R4_XX_maintenance branch, one must follow RC2 criteria, which are:
 
"All fixes submitted must have a project lead or PMC vote on the bug report, and the fix must be reviewed by an additional committer (any committer other than the one who made the fix). A positive review from a project lead or PMC member means implicit approval and no vote is needed on the bug report."
 
I read it this way:
 
1) On gerrit with backported patch ask for the "+1" review from or from PL/PMC or from a committer that was not the original patch owner.
The committer who backports the patch but is not the owner of the original patch, is also allowed to vote with "+1".
2) If the "+1" reviewer on gerrit is not PL/PMC, ask them in a comment on original bug for an explicit "+1" for backporting.
3) If 1) and 2) are successfully done, and tests are OK, gerrit can be merged.
4) API changes or new features backported require additionally explicit PMC approval.
 
Is this above right so far?
 
The only question regarding point 2) I have is: do we really need PL/PMC to be involved, even if we don't build anything from the sources and in theory nobody is at risk?
The PL/PMC vote is worrying me, looking on the number of JDT core fixes I've backported so far on 4.12 branch and the known lack of resources in JDT team.
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих


https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Freitag, 28. Februar 2020 um 14:54 Uhr
Von: "Daniel Megert" <[hidden email]>
An: "Eclipse platform release engineering list." <[hidden email]>, "Eclipse platform general developers list." <[hidden email]>
Betreff: Re: [platform-releng-dev] 4.15 maintenance branch

Hi Andrey

Thanks for bringing this up.

Since the release train moved to a quarterly release cycle there was zero interest to contribute to the maintenance branches that get created when moving to the next release. It was only used by IBM and fed with backports by IBMers (maybe with some exceptions that I can't remember right now). Right from the beginning IBM wanted to make those fixes available for everyone and not keep them in a private branch. It would be great if other people use the maintenance branches (also old ones) to backport critical fixes, or fixes that are important to their work/product/company.

Given that the code is merged after RC2, the same rules must be followed as for RC2 in https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_15.php. This also means: no API changes or feature work without PMC approval.

The Platform Releng team will not spend resources to do maintenance builds. However, anyone can use the source and build it but must not expect the Platform Releng team to hold hands.

So, welcome Andrey!
Dani




From:        Andrey Loskutov <[hidden email]>
To:        "Eclipse platform release engineering list." <[hidden email]>, "Eclipse platform general developers list." <[hidden email]>
Date:        27.02.2020 21:03
Subject:        [EXTERNAL] [platform-releng-dev] 4.15 maintenance branch
Sent by:        [hidden email]



Hi all,

since we've started with Eclipse quarterly release cadence we've
basically stopped development on maintenance branch. I saw that few
commits were done here and there, but I didn't found any strategy /
guidance.

In short, I maintain private 4.12 SDK branch with lot of backported
patches from master. I do this for our product, and I plan to start
another maintenance branch for 4.15 soon.

This time I believe it would make sense to not maintain my own private
branch, but just push backported patches we need to the "official"
R4_15_maintenance branch.

What would be the "right" way to do so? Do I need any approval from
component leads, do I need extra bugs opened to backport regression
fixes, any "+1" from other developers? Or can I just push, run gerrit
build, and if it is green, merge? Since no one seem to work on
maintenance branches anyway, this should be not a problem for anyone?

Another question would be if we could produce some regular SDK snapshot
builds from that branch, and if there are resources & interest for this?
I personally don't need that build, we build SDK locally, but it could
be something people are searching for.

I'm asking here because I believe it makes sense to give results of my
(paid) maintenance work back to community, and it is really sad to see
people searching for some fixes on a "known good" SDK version but seeing
only the way to get a new major SDK version with new unknown regressions
instead.

Please note, I do not plan to maintain backports branch for every major
SDK release, I have only resources (and plan) to do this for *some*
releases.

So there are basically two questions:

1) What are the rules for backporting patches to maintenance branch?
2) Any interest in producing SDK builds from this branch?

--
Kind regards,
Andrey Loskutov


https://www.eclipse.org/user/aloskutov
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------
_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-releng-dev


_______________________________________________ platform-releng-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev_______________________________________________
platform-releng-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-releng-dev


_______________________________________________ platform-releng-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev
_______________________________________________
platform-releng-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev
 


_______________________________________________
platform-releng-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev