You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Neil C Smith <ne...@apache.org> on 2019/10/22 10:13:00 UTC
[DISCUSS] Handling release updates
Hi All,
A few recent emails make me think that there's at least the
possibility we'll want to consider some cherry-picked module updates
for 11.2 over the next month or so, assuming the release goes through
OK.
At present I think we've only done this once for 11.0 with the gradle
patch update? That process seemed a little unwieldy to me, and
somewhat detached from our build server?! Or maybe that's me
mis-remembering things?
I'm wondering whether if we do ship updates, we trigger a new
milestone in the release branch, and have a vote on full sources, as
per normal. Alongside that we nominate specific module convenience
binaries (nbms) to be added to the mirrors / update centre.
That seems a potentially easier way to handle this. On the downside,
it may require keeping both the original and updated source bundles on
the mirrors? I'm also wondering what the mirroring / archiving
implications of overwriting specific nbms are?
We would possibly end up with a dist structure something like -
11.2 /
11.2 source
11.2 binaries
nbms /
update centre
11.2-update1
11.2-update1 source
Any thoughts? Barking up wrong tree? :-)
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 23 Oct 2019 at 14:40, Eric Barboni <sk...@apache.org> wrote:
>
> What are the distribution nbms ? I see nbms in dist but they have all an asc file associated.
Yes, those. They have .asc files. But that's not the same as NBM /
JAR signing. eg. link Reema shared when this was last discussed -
https://reference.apache.org/pmc/codesigning
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: [DISCUSS] Handling release updates
Posted by Eric Barboni <sk...@apache.org>.
What are the distribution nbms ? I see nbms in dist but they have all an asc file associated.
Regards
Eric
-----Message d'origine-----
De : Neil C Smith <ne...@apache.org>
Envoyé : mercredi 23 octobre 2019 13:19
À : dev <de...@netbeans.apache.org>
Objet : Re: [DISCUSS] Handling release updates
On Tue, 22 Oct 2019 at 11:13, Neil C Smith <ne...@apache.org> wrote:
> I'm wondering whether if we do ship updates, we trigger a new
> milestone in the release branch, and have a vote on full sources, as
> per normal. Alongside that we nominate specific module convenience
> binaries (nbms) to be added to the mirrors / update centre.
Two further thoughts on that -
* we would either need to merge the catalog info to include the new modules OR we remove the 11.2/nbms folder completely and link to 11.2-update1/nbms ? Second way simpler, but we end up with new build versions of all modules.
* currently the distribution nbms aren't signed as far as I know?! What are the implications for updates there?
Some thoughts here would be good! How do we best handle this at ASF?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Montag, den 28.10.2019, 19:24 +0000 schrieb Neil C Smith:
> On Mon, 28 Oct 2019 at 19:00, Matthias Bläsing
> <mb...@doppel-helix.eu> wrote:
> > if I'm not mistaken, currently the NBMs we produce are not signed when
> > we release. This is what I suggest:
>
> No, they're not.
I just remembered, where I saw this in the build:
nb/updatecenters/build.xml
there a new signing key is created, the nbms for javafx and nbjavac are
build and signed with that key. Then the public key/certificate is
embedded in the build as ide.ks.
ide.ks is provided by
org.netbeans.modules.updatecenters.resources.NetBeansKeyStoreProvider
to the update center to be used to check the signatures embedded in the
NBMs (see the META-INF directory of the javafx/nbjavac nbms to see the
signature).
That way the NBMs are fully trusted by the IDE and don't even trigger
the Validation dialog (so far my reading of the update center gui).
My idea would add a trusted certificate to ide.ks, that corresponds
with a signing key, that only PMC members have access to.
> > - all updates will be signed with that key, as it is trusted, it can be
> > used to safely install updates
>
> How, or actually, where? That would still be a manual, local, job?
> It would be great if we could sign during the Jenkins build. Or does
> that just open another can of worms?
Yes my idea would be to require the release manager to get the signing
key from the SVN, decrypt it with his/her GPG key, use it to sign the
update-center nbms and the remove the signing key again.
> The other option that comes to mind - Jan mentioned validating the GPG
> signatures - but would it be possible to just get the IDE to use our
> KEYS file as a source for validation?
Then you need to artifacts: The NBM and its corresponding detached
signature. I agree, that it is possible to verify the signature that
way, but how to get them combined? And we would still need to push an
update to the current install base.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 28 Oct 2019 at 19:00, Matthias Bläsing
<mb...@doppel-helix.eu> wrote:
> if I'm not mistaken, currently the NBMs we produce are not signed when
> we release. This is what I suggest:
No, they're not.
> - all updates will be signed with that key, as it is trusted, it can be
> used to safely install updates
How, or actually, where? That would still be a manual, local, job?
It would be great if we could sign during the Jenkins build. Or does
that just open another can of worms?
The other option that comes to mind - Jan mentioned validating the GPG
signatures - but would it be possible to just get the IDE to use our
KEYS file as a source for validation?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Sonntag, den 27.10.2019, 12:18 +0100 schrieb Jan Lahoda:
> [How to handle updates]
> But I have no idea if we asked to an access there. (And if ASF would pay
> for each signed file, then singing several hundreds NBMs would not fly
> anyway, I think.) But we could at least use that for this update release
> (which will likely only consist of a handful of NBMs), and try to do
> something better for the future.
if I'm not mistaken, currently the NBMs we produce are not signed when
we release. This is what I suggest:
- lets create a signing key for the netbeans releases, place the
private key on the PMC SVN directory, as is done with the SSH key to
access the ousol binaries site
- add the public key for the signing key as a trusted code signing
certificate to the netbeans distribution
- all updates will be signed with that key, as it is trusted, it can be
used to safely install updates
- we should make sure, that we can handle multiple trusted keys,
that way we can push a new key, using an existing key
This still requires once a manual installation of the first netbeans
version, that carries the key. What do you think?
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 28 Oct 2019 at 18:16, Geertjan Wielenga <ge...@apache.org> wrote:
> How are we doing in this discussion, at least, what can we do to release
> the fix to the nb-javac which, without it, will otherwise cause refactoring
> to fail if nb-javac is installed?
We need it merged to master. We ideally need a temporary UC where
people can check it works OK with NB 11.2. We need a cherry-picked PR
for release112. We need to vote on a new source zip (along with any
other fixes we want to include in a patch release). We need to upload
changed nbms and edit the catalog.
All that is mostly, OK. At some point in that we really need to
figure out how to sign the updated NBMs though.
Also interested in Eric's view on using Maven for updates, because
this might be a better place to link the new NBMs from?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Geertjan Wielenga <ge...@apache.org>.
Hi all,
How are we doing in this discussion, at least, what can we do to release
the fix to the nb-javac which, without it, will otherwise cause refactoring
to fail if nb-javac is installed?
Gj
On Sun, Oct 27, 2019 at 12:19 PM Jan Lahoda <la...@gmail.com> wrote:
> On Fri, Oct 25, 2019 at 1:04 PM Neil C Smith <ne...@apache.org>
> wrote:
>
> > On Thu, 24 Oct 2019 at 21:17, Jan Lahoda <la...@gmail.com> wrote:
> > >> Still unsure about how we handle catalog and signing issues though.
> > >> Am I right in thinking with current situation people will see a
> > >> warning on update? Definitely see this already when re-enabling
> > >> nb-javac.
> > >
> > > That is one of the things I'd like to try. The update will be a two
> > phase process - first update the nb/updatecenters module, and then
> > nb-javac. I *think* there should be no warning for the second update
> > (because the NBM is signed using the key that is embedded in the
> > updatecenters module), but I am less sure about how exactly the first
> > update will work.
> >
> > I'm fairly sure the first update at least will show a warning.
> > Installing other nbms from the distribution UC does now.
> >
>
> Yes, i am afraid so, unless we find a way to sensibly sign the NBMs.
>
> There is this (which is probably what Reema shared):
> https://blogs.apache.org/infra/entry/code_signing_service_now_available
>
> But I have no idea if we asked to an access there. (And if ASF would pay
> for each signed file, then singing several hundreds NBMs would not fly
> anyway, I think.) But we could at least use that for this update release
> (which will likely only consist of a handful of NBMs), and try to do
> something better for the future.
>
> But the second update should be without warning, if the NBMs is done
> properly.
>
>
> > Check the link Reema shared that I posted earlier. We might be able
> > to use that, in the short term manually signing the relevant updates
> > via the web interface? Except that shows a browser security error for
> > me. And also specifies .jar extension.
> >
> > What other options are there? Is there any *secure* way that we can
> > add trust in the IDE for modules built on ASF infrastructure? If I
> > understand it correctly, the current way the third-party UC does this
> > will only work for a single build?
> >
>
> I wonder if we could validate the GPG signatures (.asc) we need to use
> anyway - the IDE could then have a list of "trusted" KEYs.
>
> Jan
>
>
> > Best wishes,
> >
> > Neil
> >
>
Re: [DISCUSS] Handling release updates
Posted by Jan Lahoda <la...@gmail.com>.
On Fri, Oct 25, 2019 at 1:04 PM Neil C Smith <ne...@apache.org> wrote:
> On Thu, 24 Oct 2019 at 21:17, Jan Lahoda <la...@gmail.com> wrote:
> >> Still unsure about how we handle catalog and signing issues though.
> >> Am I right in thinking with current situation people will see a
> >> warning on update? Definitely see this already when re-enabling
> >> nb-javac.
> >
> > That is one of the things I'd like to try. The update will be a two
> phase process - first update the nb/updatecenters module, and then
> nb-javac. I *think* there should be no warning for the second update
> (because the NBM is signed using the key that is embedded in the
> updatecenters module), but I am less sure about how exactly the first
> update will work.
>
> I'm fairly sure the first update at least will show a warning.
> Installing other nbms from the distribution UC does now.
>
Yes, i am afraid so, unless we find a way to sensibly sign the NBMs.
There is this (which is probably what Reema shared):
https://blogs.apache.org/infra/entry/code_signing_service_now_available
But I have no idea if we asked to an access there. (And if ASF would pay
for each signed file, then singing several hundreds NBMs would not fly
anyway, I think.) But we could at least use that for this update release
(which will likely only consist of a handful of NBMs), and try to do
something better for the future.
But the second update should be without warning, if the NBMs is done
properly.
> Check the link Reema shared that I posted earlier. We might be able
> to use that, in the short term manually signing the relevant updates
> via the web interface? Except that shows a browser security error for
> me. And also specifies .jar extension.
>
> What other options are there? Is there any *secure* way that we can
> add trust in the IDE for modules built on ASF infrastructure? If I
> understand it correctly, the current way the third-party UC does this
> will only work for a single build?
>
I wonder if we could validate the GPG signatures (.asc) we need to use
anyway - the IDE could then have a list of "trusted" KEYs.
Jan
> Best wishes,
>
> Neil
>
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 24 Oct 2019 at 21:17, Jan Lahoda <la...@gmail.com> wrote:
>> Still unsure about how we handle catalog and signing issues though.
>> Am I right in thinking with current situation people will see a
>> warning on update? Definitely see this already when re-enabling
>> nb-javac.
>
> That is one of the things I'd like to try. The update will be a two phase process - first update the nb/updatecenters module, and then nb-javac. I *think* there should be no warning for the second update (because the NBM is signed using the key that is embedded in the updatecenters module), but I am less sure about how exactly the first update will work.
I'm fairly sure the first update at least will show a warning.
Installing other nbms from the distribution UC does now.
Check the link Reema shared that I posted earlier. We might be able
to use that, in the short term manually signing the relevant updates
via the web interface? Except that shows a browser security error for
me. And also specifies .jar extension.
What other options are there? Is there any *secure* way that we can
add trust in the IDE for modules built on ASF infrastructure? If I
understand it correctly, the current way the third-party UC does this
will only work for a single build?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Jan Lahoda <la...@gmail.com>.
On Thu, Oct 24, 2019 at 11:07 AM Neil C Smith <ne...@apache.org> wrote:
> On Thu, 24 Oct 2019 at 09:48, Jan Lahoda <la...@gmail.com> wrote:
> > Releasing the full source does sound easier for processes, so if
> reviewers are ok with that, sounds good to me. Should be possible to only
> upload specific NBMs. I guess the question is when we do the update, given
> the refactoring is broken for 9+.
>
> I'm thinking maybe ~2 weeks? Given there is a workaround
> (uninstalling nb-javac) and the potential for other things that have
> been mentioned to maybe require fixes, we could aim for a patch
> release then?
>
> In the meantime, could we also provide an additional update centre for
> nb-javac so that people who want to can install and test the fixed
> version? And is the fixed version ready yet anyway?
>
Should be this, I believe:
https://github.com/apache/netbeans/pull/1589
I would like to try myself, to check that things are working, but didn't
get to that.
> Still unsure about how we handle catalog and signing issues though.
> Am I right in thinking with current situation people will see a
> warning on update? Definitely see this already when re-enabling
> nb-javac.
>
That is one of the things I'd like to try. The update will be a two phase
process - first update the nb/updatecenters module, and then nb-javac. I
*think* there should be no warning for the second update (because the NBM
is signed using the key that is embedded in the updatecenters module), but
I am less sure about how exactly the first update will work.
Jan
> How do we address that? Can we add anything in to our existing build
> process within that timeframe?
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 24 Oct 2019 at 09:48, Jan Lahoda <la...@gmail.com> wrote:
> Releasing the full source does sound easier for processes, so if reviewers are ok with that, sounds good to me. Should be possible to only upload specific NBMs. I guess the question is when we do the update, given the refactoring is broken for 9+.
I'm thinking maybe ~2 weeks? Given there is a workaround
(uninstalling nb-javac) and the potential for other things that have
been mentioned to maybe require fixes, we could aim for a patch
release then?
In the meantime, could we also provide an additional update centre for
nb-javac so that people who want to can install and test the fixed
version? And is the fixed version ready yet anyway?
Still unsure about how we handle catalog and signing issues though.
Am I right in thinking with current situation people will see a
warning on update? Definitely see this already when re-enabling
nb-javac.
How do we address that? Can we add anything in to our existing build
process within that timeframe?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Jan Lahoda <la...@gmail.com>.
Releasing the full source does sound easier for processes, so if reviewers are ok with that, sounds good to me. Should be possible to only upload specific NBMs. I guess the question is when we do the update, given the refactoring is broken for 9+.
Jan
23. října 2019 15:03:03 SELČ, Neil C Smith <ne...@apache.org> napsal:
>On Wed, 23 Oct 2019 at 13:55, Geertjan Wielenga <ge...@apache.org>
>wrote:
>>
>> Agree completely. I suggest you put your proposal in a lazy consensus
>> thread.
>
>It's a best a half-baked proposal! :-) I was hoping for some input
>and discussion first to clarify what we need and how best to achieve.
>
>Best wishes,
>
>Neil
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>For additional commands, e-mail: dev-help@netbeans.apache.org
>
>For further information about the NetBeans mailing lists, visit:
>https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
--
Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji stručnost.
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 23 Oct 2019 at 13:55, Geertjan Wielenga <ge...@apache.org> wrote:
>
> Agree completely. I suggest you put your proposal in a lazy consensus
> thread.
It's a best a half-baked proposal! :-) I was hoping for some input
and discussion first to clarify what we need and how best to achieve.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Geertjan Wielenga <ge...@apache.org>.
Agree completely. I suggest you put your proposal in a lazy consensus
thread.
Gj
On Wed, Oct 23, 2019 at 2:52 PM Neil C Smith <ne...@apache.org> wrote:
> On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga <ge...@apache.org>
> wrote:
> > Will we really need to go through a vote process for this change?
>
> IMO, yes - it's still a source change. And that's not quite the only
> change required.
>
> But there are other things we might want to make patches for too.
> This thread was not meant to be specific to that one particular issue.
> We need to work out a process for how we do this in future.
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 8 Nov 2019, 10:35 Geertjan Wielenga, <ge...@apache.org> wrote:
> How is the signing done for Apache NetBeans during releases and why can't
> that be used for the patch too?
>
Different kinds of signing. The releases and the updates will be signed as
ASF requires with an external .asc file. But the nbms in the release aren't
currently jar signed (ie. internal signature) so will show as unsigned with
a warning in the IDE. You can see this if you uninstall and reinstall
modules in the IDE. This is what we need to sort out.
And yes, you're not the only one to have been confused by this distinction!
;-)
Best wishes,
Neil
>
Re: [DISCUSS] Handling release updates
Posted by Geertjan Wielenga <ge...@apache.org>.
How is the signing done for Apache NetBeans during releases and why can't
that be used for the patch too? Sorry, ignorant on this point and need to
understand this aspect to be able to participate in the discussion,
alternatively those who are familiar with this should take the lead and do
what is needed or what is best under the circumstances.
Gj
On Thu, Nov 7, 2019 at 6:22 PM Neil C Smith <ne...@apache.org> wrote:
> On Thu, 7 Nov 2019 at 17:05, Korney Czukowski <cz...@seznam.cz> wrote:
> > Although even with almost
> > everything in place, there's still this issue with nbm signing, so
> > practically the Update Center cannot be used for now, right (else you
> > would have already used it)? If this is the case, then a (trusted)
> > offline installed could be used as a temporarily and somewhat ugly
> solution.
>
> The UC is useful now, and can be used for things like RCP harness
> building. However, the iDE will show a warning for nbms there.
>
> All binary elements, including the zips and nbms, are already gpg
> signed locally. We just need a temporary solution to (jar) sign the
> updated nbm files as well. The solution you suggest would actually be
> more complicated not less. We still have to sign them! Getting them
> in the existing UC is easy after that.
>
> Thanks,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 7 Nov 2019 at 17:05, Korney Czukowski <cz...@seznam.cz> wrote:
> Although even with almost
> everything in place, there's still this issue with nbm signing, so
> practically the Update Center cannot be used for now, right (else you
> would have already used it)? If this is the case, then a (trusted)
> offline installed could be used as a temporarily and somewhat ugly solution.
The UC is useful now, and can be used for things like RCP harness
building. However, the iDE will show a warning for nbms there.
All binary elements, including the zips and nbms, are already gpg
signed locally. We just need a temporary solution to (jar) sign the
updated nbm files as well. The solution you suggest would actually be
more complicated not less. We still have to sign them! Getting them
in the existing UC is easy after that.
Thanks,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Korney Czukowski <cz...@seznam.cz>.
Then I must have misunderstood your earlier comment about issues due to
changes in the build system, my apologies. Although even with almost
everything in place, there's still this issue with nbm signing, so
practically the Update Center cannot be used for now, right (else you
would have already used it)? If this is the case, then a (trusted)
offline installed could be used as a temporarily and somewhat ugly solution.
And yes, I meant generally any release within the quarterly cycle that
is assigned a version number, sorry for not being clear.
Regards!
On 2019/11/07 16:24:54, Neil C Smith <n...@apache.orgwrote:
> On Thu, 7 Nov 2019 at 16:14, Korney Czukowski <cz...@seznam.czwrote:
>> If the Update Center is out of the question for now,
> <snip> it isn't! That bit is not the problem. The only problem to
> delivery at the moment is signing the nbm with a certificate that's
> trusted by the IDE.
>> Of course, both options should be viewed only as a temporary solution
>> for situations where you guys really want to push an update ASAP. IMO,
>> the end goal should be that any module that NetBeans platform can
>> possibly live without, can be installed or updated from the Update
>> Center by default, and the incremental releases with the version numbers
>> would just include the most recent stable versions of those modules.
> That is already the case, although not quite sure what you mean by
> incremental releases - note that 11.2. is not an incremental release.
>
> There is just the issue again that the nbms in that distribution
> update centre are not signed at present.
>
> eg. 11.2 is all at
> https://dist.apache.org/repos/dist/release/netbeans/netbeans/11.2/nbms/
>
> Longer term the Apache mirrors may not be the best way to distribute
> the modules though.
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 7 Nov 2019 at 16:14, Korney Czukowski <cz...@seznam.cz> wrote:
> If the Update Center is out of the question for now,
<snip> it isn't! That bit is not the problem. The only problem to
delivery at the moment is signing the nbm with a certificate that's
trusted by the IDE.
> Of course, both options should be viewed only as a temporary solution
> for situations where you guys really want to push an update ASAP. IMO,
> the end goal should be that any module that NetBeans platform can
> possibly live without, can be installed or updated from the Update
> Center by default, and the incremental releases with the version numbers
> would just include the most recent stable versions of those modules.
That is already the case, although not quite sure what you mean by
incremental releases - note that 11.2. is not an incremental release.
There is just the issue again that the nbms in that distribution
update centre are not signed at present.
eg. 11.2 is all at
https://dist.apache.org/repos/dist/release/netbeans/netbeans/11.2/nbms/
Longer term the Apache mirrors may not be the best way to distribute
the modules though.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Korney Czukowski <cz...@seznam.cz>.
If the Update Center is out of the question for now, maybe it would be
feasible to create an offline update installer consisting only of a
couple of nbms that need to be updated, that would update an existing
NetBeans installation? Then it should be possible to vote for just for
this very limited portion of the sources and avoid issues with early
merging. If the installer is signed, there should not be any trust
issues regarding the content it carries.
If this is hard to do, maybe even just posting the patched nbms
somewhere and instructing the affected users how to replace them
manually could suffice, given the NetBeans userbase profile, it might be
acceptable to many.
Of course, both options should be viewed only as a temporary solution
for situations where you guys really want to push an update ASAP. IMO,
the end goal should be that any module that NetBeans platform can
possibly live without, can be installed or updated from the Update
Center by default, and the incremental releases with the version numbers
would just include the most recent stable versions of those modules.
On 2019/11/07 10:56:49, Neil C Smith <n....@apache.org> wrote:
> On Thu, 7 Nov 2019 at 10:43, Geertjan Wielenga <ge...@apache.org>
wrote:>
> > Can someone -- preferably Eric, Neil, Laszlo, Jan, or Matthias,
suggest a>
> > way forward to get an update out, i.e., we could even call it 11.2.1,>
> > maybe, if we can't figure out how to release the two modules (what
would be>
> > the problem with doing it as Laszlo did for Gradle)?>
>
> We can't do it as Laszlo did for Gradle because of changes in the>
> build system. And in many respects this should be simpler.>
>
> We need to>
>
> * merge the relevant PRs to master and test. (perhaps provide nbms via>
> temporary UC?)>
> * (ideally) cherry pick locally and open new PRs on top of release112>
> (better than pushing to release branch IMO because of Travis, etc.)>
> * Merge to release branch.>
> * write the hash into the release JSON file (probably 11.2-patch1) and>
> trigger a build.>
> * ***somehow*** sign the relevant nbms.>
> * vote on source zip and required nbms.>
>
> There is one more potential PR for the patch update. They all have>
> Cherry Pick labels on them.>
>
>
https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aopen+label%3A%22Cherry+Pick%22>
>
> I'm happy to RM the process from point 3, but I'd rather the current>
> PR authors handled steps 1 and 2. If I do, add me as a reviewer on>
> the step 2 PR when they're ready.>
>
> And we still need an answer for the signing part for 11.2 updates ->
> perhaps the web signing via Apache is the way, but I'll need to follow>
> up with infra. Few suggestions for 11.3+ are great there but don't>
> help us with this update.>
>
> Best wishes,>
>
> Neil>
>
> --------------------------------------------------------------------->
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org>
> For additional commands, e-mail: dev-help@netbeans.apache.org>
>
> For further information about the NetBeans mailing lists, visit:>
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 7 Nov 2019 at 10:43, Geertjan Wielenga <ge...@apache.org> wrote:
> Can someone -- preferably Eric, Neil, Laszlo, Jan, or Matthias, suggest a
> way forward to get an update out, i.e., we could even call it 11.2.1,
> maybe, if we can't figure out how to release the two modules (what would be
> the problem with doing it as Laszlo did for Gradle)?
We can't do it as Laszlo did for Gradle because of changes in the
build system. And in many respects this should be simpler.
We need to
* merge the relevant PRs to master and test. (perhaps provide nbms via
temporary UC?)
* (ideally) cherry pick locally and open new PRs on top of release112
(better than pushing to release branch IMO because of Travis, etc.)
* Merge to release branch.
* write the hash into the release JSON file (probably 11.2-patch1) and
trigger a build.
* ***somehow*** sign the relevant nbms.
* vote on source zip and required nbms.
There is one more potential PR for the patch update. They all have
Cherry Pick labels on them.
https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aopen+label%3A%22Cherry+Pick%22
I'm happy to RM the process from point 3, but I'd rather the current
PR authors handled steps 1 and 2. If I do, add me as a reviewer on
the step 2 PR when they're ready.
And we still need an answer for the signing part for 11.2 updates -
perhaps the web signing via Apache is the way, but I'll need to follow
up with infra. Few suggestions for 11.3+ are great there but don't
help us with this update.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Geertjan Wielenga <ge...@apache.org>.
Can someone -- preferably Eric, Neil, Laszlo, Jan, or Matthias, suggest a
way forward to get an update out, i.e., we could even call it 11.2.1,
maybe, if we can't figure out how to release the two modules (what would be
the problem with doing it as Laszlo did for Gradle)?
Gj
On Thu, Nov 7, 2019 at 11:05 AM Geertjan Wielenga <ge...@apache.org>
wrote:
> There appear to be two issues that would be best to make available as
> updates as soon as we can -- relating to nb-javac and HTML parsing.
>
> What would be the problem with voting on the sources of those two modules
> and then making them available via the plugin portal?
>
> Gj
>
> On Mon, Nov 4, 2019 at 6:54 PM Eric Barboni <sk...@apache.org> wrote:
>
>> Hi,
>> Not sure what the needs exactly.
>> But If you rebuild a patched NetBeans with a forced version
>> RELEASE112-update1. You can pick the patched nbm you want. And alter pom to
>> put RELEASE112 for dep (you know are were not modified).
>>
>> Then vote with sources + the limited artefacts RELEASE112-update1 to be
>> able to release them in central
>>
>> Best Regards
>> Eric
>>
>>
>>
>>
>> -----Message d'origine-----
>> De : Neil C Smith <ne...@apache.org>
>> Envoyé : mardi 29 octobre 2019 18:42
>> À : dev <de...@netbeans.apache.org>
>> Objet : Re: [DISCUSS] Handling release updates
>>
>> On Tue, 29 Oct 2019 at 15:53, Eric Barboni <sk...@apache.org> wrote:
>> > You cannot do a RELEASE112.1 in the
>> org.netbeans(api,modules,clusters,external) without rebuild the whole
>> NetBeans stack because every pom will need the RELEASE112.1 version on
>> dependencies nbm being a side artefacts.
>> > It's not possible to overwrite a released artefacts you cannot do a
>> RELEASE112 again.
>>
>> Yes, I know artefacts can't be overwritten, so thought as much. Kind of
>> makes it even harder to push a patch release for Maven modules.
>> Would be good if that was not the case, but I guess it's not a short term
>> (ie. 11.2 update) mechanism. And Maven probably won't get nb-javac module
>> fix, although that's probably not that much of an issue.
>>
>> Still think it worth considering longer term. Means only one set of NBMs
>> need signing and maintaining, and may remove some issues around using
>> Apache mirrors for the UCs. How feasible is changing the modules to use
>> spec version and RELEASE11X just for overarching POM files?
>>
>> Best wishes,
>>
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
Re: [DISCUSS] Handling release updates
Posted by Geertjan Wielenga <ge...@apache.org>.
There appear to be two issues that would be best to make available as
updates as soon as we can -- relating to nb-javac and HTML parsing.
What would be the problem with voting on the sources of those two modules
and then making them available via the plugin portal?
Gj
On Mon, Nov 4, 2019 at 6:54 PM Eric Barboni <sk...@apache.org> wrote:
> Hi,
> Not sure what the needs exactly.
> But If you rebuild a patched NetBeans with a forced version
> RELEASE112-update1. You can pick the patched nbm you want. And alter pom to
> put RELEASE112 for dep (you know are were not modified).
>
> Then vote with sources + the limited artefacts RELEASE112-update1 to be
> able to release them in central
>
> Best Regards
> Eric
>
>
>
>
> -----Message d'origine-----
> De : Neil C Smith <ne...@apache.org>
> Envoyé : mardi 29 octobre 2019 18:42
> À : dev <de...@netbeans.apache.org>
> Objet : Re: [DISCUSS] Handling release updates
>
> On Tue, 29 Oct 2019 at 15:53, Eric Barboni <sk...@apache.org> wrote:
> > You cannot do a RELEASE112.1 in the
> org.netbeans(api,modules,clusters,external) without rebuild the whole
> NetBeans stack because every pom will need the RELEASE112.1 version on
> dependencies nbm being a side artefacts.
> > It's not possible to overwrite a released artefacts you cannot do a
> RELEASE112 again.
>
> Yes, I know artefacts can't be overwritten, so thought as much. Kind of
> makes it even harder to push a patch release for Maven modules.
> Would be good if that was not the case, but I guess it's not a short term
> (ie. 11.2 update) mechanism. And Maven probably won't get nb-javac module
> fix, although that's probably not that much of an issue.
>
> Still think it worth considering longer term. Means only one set of NBMs
> need signing and maintaining, and may remove some issues around using
> Apache mirrors for the UCs. How feasible is changing the modules to use
> spec version and RELEASE11X just for overarching POM files?
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
RE: [DISCUSS] Handling release updates
Posted by Eric Barboni <sk...@apache.org>.
Hi,
Not sure what the needs exactly.
But If you rebuild a patched NetBeans with a forced version RELEASE112-update1. You can pick the patched nbm you want. And alter pom to put RELEASE112 for dep (you know are were not modified).
Then vote with sources + the limited artefacts RELEASE112-update1 to be able to release them in central
Best Regards
Eric
-----Message d'origine-----
De : Neil C Smith <ne...@apache.org>
Envoyé : mardi 29 octobre 2019 18:42
À : dev <de...@netbeans.apache.org>
Objet : Re: [DISCUSS] Handling release updates
On Tue, 29 Oct 2019 at 15:53, Eric Barboni <sk...@apache.org> wrote:
> You cannot do a RELEASE112.1 in the org.netbeans(api,modules,clusters,external) without rebuild the whole NetBeans stack because every pom will need the RELEASE112.1 version on dependencies nbm being a side artefacts.
> It's not possible to overwrite a released artefacts you cannot do a RELEASE112 again.
Yes, I know artefacts can't be overwritten, so thought as much. Kind of makes it even harder to push a patch release for Maven modules.
Would be good if that was not the case, but I guess it's not a short term (ie. 11.2 update) mechanism. And Maven probably won't get nb-javac module fix, although that's probably not that much of an issue.
Still think it worth considering longer term. Means only one set of NBMs need signing and maintaining, and may remove some issues around using Apache mirrors for the UCs. How feasible is changing the modules to use spec version and RELEASE11X just for overarching POM files?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 29 Oct 2019 at 15:53, Eric Barboni <sk...@apache.org> wrote:
> You cannot do a RELEASE112.1 in the org.netbeans(api,modules,clusters,external) without rebuild the whole NetBeans stack because every pom will need the RELEASE112.1 version on dependencies nbm being a side artefacts.
> It's not possible to overwrite a released artefacts you cannot do a RELEASE112 again.
Yes, I know artefacts can't be overwritten, so thought as much. Kind
of makes it even harder to push a patch release for Maven modules.
Would be good if that was not the case, but I guess it's not a short
term (ie. 11.2 update) mechanism. And Maven probably won't get
nb-javac module fix, although that's probably not that much of an
issue.
Still think it worth considering longer term. Means only one set of
NBMs need signing and maintaining, and may remove some issues around
using Apache mirrors for the UCs. How feasible is changing the
modules to use spec version and RELEASE11X just for overarching POM
files?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: [DISCUSS] Handling release updates
Posted by Eric Barboni <sk...@apache.org>.
Sorry did not get this part,
It's possible to generate catalog to link to maven central (will need some works to be sure to get all info maybe). It's a public repo. Nbm file are the same as the one in official release.
Not sure following are pro/cons, just "idea" based on current status of tools (nb-repository-plugin) for the patch case if needed
You cannot do a RELEASE112.1 in the org.netbeans(api,modules,clusters,external) without rebuild the whole NetBeans stack because every pom will need the RELEASE112.1 version on dependencies nbm being a side artefacts.
It's not possible to overwrite a released artefacts you cannot do a RELEASE112 again.
Hope It helps,
Best regards
Eric
-----Message d'origine-----
De : Neil C Smith <ne...@apache.org>
Envoyé : samedi 26 octobre 2019 20:20
À : dev <de...@netbeans.apache.org>
Objet : Re: [DISCUSS] Handling release updates
On Sat, 26 Oct 2019 at 05:17, Laszlo Kishalmi <la...@gmail.com> wrote:
> You put tremendous effort in the new pipeline to work
Credit where credit is due, the bulk of that effort was Eric. Now thinking about it, one reason for the new build system is Maven artefacts. Which, include the NBMs as is as far as I know? And will need to have the same updates that we ship to the IDE.
So, Eric / anyone - could we generate a distribution catalog.xml that uses Maven hosted nbms instead of the mirrors? The catalog itself could remain hosted on the VM where it is now. What pros / cons?
> Let's listen for other ideas as well...
Yes, agreed! Sorry, wasn't aiming to stop discussion, just pointing out that splitting distribution UCs would involve more changes than just adding it in - e.g the new build system and the RCP build harness would probably need rethinking to support multiple sources.
One other infrastructure problem we have is that the catalog.xml links are relative, which means every module downloaded goes through the same redirects. Works for odd module updates, but seems to get refused with too many requests - try using the above mentioned RCP harness download, or installing an entire cluster, and it will probably fail. One other thing that would be good to solve in this discussion - ideally only the catalog itself needs to be done via .htaccess.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Sat, 26 Oct 2019 at 05:17, Laszlo Kishalmi <la...@gmail.com> wrote:
> You put tremendous effort in the new pipeline to work
Credit where credit is due, the bulk of that effort was Eric. Now
thinking about it, one reason for the new build system is Maven
artefacts. Which, include the NBMs as is as far as I know? And will
need to have the same updates that we ship to the IDE.
So, Eric / anyone - could we generate a distribution catalog.xml that
uses Maven hosted nbms instead of the mirrors? The catalog itself
could remain hosted on the VM where it is now. What pros / cons?
> Let's listen for other ideas as well...
Yes, agreed! Sorry, wasn't aiming to stop discussion, just pointing
out that splitting distribution UCs would involve more changes than
just adding it in - e.g the new build system and the RCP build harness
would probably need rethinking to support multiple sources.
One other infrastructure problem we have is that the catalog.xml links
are relative, which means every module downloaded goes through the
same redirects. Works for odd module updates, but seems to get
refused with too many requests - try using the above mentioned RCP
harness download, or installing an entire cluster, and it will
probably fail. One other thing that would be good to solve in this
discussion - ideally only the catalog itself needs to be done via
.htaccess.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 10/25/19 8:55 AM, Neil C Smith wrote:
> On Fri, 25 Oct 2019 at 16:02, Laszlo Kishalmi <la...@gmail.com> wrote:
>> So anyone can step up coordinate and do a patch release of some modules
>> if the community approves that. When we are releasing the whole IDE the
>> RM has one orientation: the whole IDE.
> I'm -1 to voting on patch sources vs a whole IDE patch release (even
> if +1 to anyone else RM'ing it! ;-) ). I think the way that the patch
> release was done previously would be difficult to achieve with the new
> build system. We need to ensure that even patch releases end up with
> consistent build numbers / git hash info. I also think the patch
> voting was more complicated for voters, and "awkward" from an Apache
> compatibility point of view. Hence suggesting we still do a vote on
> the full sources built on netbeans-TLP, but only nominate required
> binaries.
Well, I'm not pushing for the partial source release/vote. You put
tremendous effort in the new pipeline to work, I very much believe that
it is easier, more reliable and safer to vote on the whole source and
nominate the required binaries.
>
> On Fri, 25 Oct 2019 at 14:01, Laszlo Kishalmi <la...@gmail.com> wrote:
>> Probably the ugliest part was the actual release of the nbms. In the
>> future we could create a separate update center for release updates and
>> ship that configured in the release. I think the new plugin portal
>> infrastructure probably could help, if that'd support multi tenancy.
> Good point on the ugly part! Although again I'd vote -1 on splitting
> the UC for the distribution in two. Mainly from a downstream
> distribution / derivative perspective - enlightened self interest at
> play there! :-)
>
> However, we do serve the catalog from the VM, and the catalog can have
> absolute rather than relative links, meaning we don't need to serve
> the updated artefacts themselves the same way.
> Still, the other thing we need to keep in mind is that we may be
> starting to ship installers that can install specific clusters. One
> way of upgrading such a release later is to install another cluster
> via UC? Not having them signed / having multiple centres may also be
> a problem there.
I'm not sure I get this, but I think that would be explained in more
detail. Let's listen for other ideas as well...
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 25 Oct 2019 at 16:02, Laszlo Kishalmi <la...@gmail.com> wrote:
> So anyone can step up coordinate and do a patch release of some modules
> if the community approves that. When we are releasing the whole IDE the
> RM has one orientation: the whole IDE.
I'm -1 to voting on patch sources vs a whole IDE patch release (even
if +1 to anyone else RM'ing it! ;-) ). I think the way that the patch
release was done previously would be difficult to achieve with the new
build system. We need to ensure that even patch releases end up with
consistent build numbers / git hash info. I also think the patch
voting was more complicated for voters, and "awkward" from an Apache
compatibility point of view. Hence suggesting we still do a vote on
the full sources built on netbeans-TLP, but only nominate required
binaries.
On Fri, 25 Oct 2019 at 14:01, Laszlo Kishalmi <la...@gmail.com> wrote:
> Probably the ugliest part was the actual release of the nbms. In the
> future we could create a separate update center for release updates and
> ship that configured in the release. I think the new plugin portal
> infrastructure probably could help, if that'd support multi tenancy.
Good point on the ugly part! Although again I'd vote -1 on splitting
the UC for the distribution in two. Mainly from a downstream
distribution / derivative perspective - enlightened self interest at
play there! :-)
However, we do serve the catalog from the VM, and the catalog can have
absolute rather than relative links, meaning we don't need to serve
the updated artefacts themselves the same way.
Still, the other thing we need to keep in mind is that we may be
starting to ship installers that can install specific clusters. One
way of upgrading such a release later is to install another cluster
via UC? Not having them signed / having multiple centres may also be
a problem there.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 10/25/19 7:17 AM, Eric Barboni wrote:
> Hi,
> Needs to be simple and formal enough to be Apache compatible.
>
> I'm afraid that if it's too complicated, a RM can cancel release vote because if it may look simpler to merge some fix and revote. Or let the bug until the next X.Y release.
> And if a RM is more java oriented he may not see c++ or web issue as important to deserve an update. (kind if Laszlo were not RM at the time maybe gradle patch would have never been set)
Well that's not entirely true. Each release has it's own RM 11.1 and
11.2 happens to be Neil. A patch release can have a different RM. What
for example you are doing with the Maven Archetypes (btw thank you for
carry on that) are RM. It is the scope of such releases are way smaller
than releasing the whole IDE.
I would have created the Gradle patch release even if I was not the RM
for the whole IDE that time, though having two releases behind my back
certainly helped to have the confidence to walk though the path.
So anyone can step up coordinate and do a patch release of some modules
if the community approves that. When we are releasing the whole IDE the
RM has one orientation: the whole IDE.
>
> Regards
> Eric
>
> -----Message d'origine-----
> De : Laszlo Kishalmi <la...@gmail.com>
> Envoyé : vendredi 25 octobre 2019 14:52
> À : dev@netbeans.apache.org
> Objet : Re: [DISCUSS] Handling release updates
>
> Well, the Gradle patch has been made in the following way:
>
> 1. The result of the release build has been further processed, extracting the source files for the changed modules and the necessary files like NOTICE and licenses.
>
> 2. So the output of the patch build was a small source zip and the corresponding nbm-s as binary. The README had the instruction that how you need to paths the existing source bundle with the new one to create the binaries.
>
> 3. We voted on the source files only
>
> 4. The nbms were overwritten in the distribution directory and the updates.xml.gz was patched by hand.
>
> Probably the ugliest part was the actual release of the nbms. In the future we could create a separate update center for release updates and ship that configured in the release. I think the new plugin portal infrastructure probably could help, if that'd support multi tenancy.
>
> On 10/23/19 5:51 AM, Neil C Smith wrote:
>> On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga <ge...@apache.org> wrote:
>>> Will we really need to go through a vote process for this change?
>> IMO, yes - it's still a source change. And that's not quite the only
>> change required.
>>
>> But there are other things we might want to make patches for too.
>> This thread was not meant to be specific to that one particular issue.
>> We need to work out a process for how we do this in future.
>>
>> Best wishes,
>>
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: [DISCUSS] Handling release updates
Posted by Eric Barboni <sk...@apache.org>.
Hi,
Needs to be simple and formal enough to be Apache compatible.
I'm afraid that if it's too complicated, a RM can cancel release vote because if it may look simpler to merge some fix and revote. Or let the bug until the next X.Y release.
And if a RM is more java oriented he may not see c++ or web issue as important to deserve an update. (kind if Laszlo were not RM at the time maybe gradle patch would have never been set)
Regards
Eric
-----Message d'origine-----
De : Laszlo Kishalmi <la...@gmail.com>
Envoyé : vendredi 25 octobre 2019 14:52
À : dev@netbeans.apache.org
Objet : Re: [DISCUSS] Handling release updates
Well, the Gradle patch has been made in the following way:
1. The result of the release build has been further processed, extracting the source files for the changed modules and the necessary files like NOTICE and licenses.
2. So the output of the patch build was a small source zip and the corresponding nbm-s as binary. The README had the instruction that how you need to paths the existing source bundle with the new one to create the binaries.
3. We voted on the source files only
4. The nbms were overwritten in the distribution directory and the updates.xml.gz was patched by hand.
Probably the ugliest part was the actual release of the nbms. In the future we could create a separate update center for release updates and ship that configured in the release. I think the new plugin portal infrastructure probably could help, if that'd support multi tenancy.
On 10/23/19 5:51 AM, Neil C Smith wrote:
> On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga <ge...@apache.org> wrote:
>> Will we really need to go through a vote process for this change?
> IMO, yes - it's still a source change. And that's not quite the only
> change required.
>
> But there are other things we might want to make patches for too.
> This thread was not meant to be specific to that one particular issue.
> We need to work out a process for how we do this in future.
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Laszlo Kishalmi <la...@gmail.com>.
Well, the Gradle patch has been made in the following way:
1. The result of the release build has been further processed,
extracting the source files for the changed modules and the necessary
files like NOTICE and licenses.
2. So the output of the patch build was a small source zip and the
corresponding nbm-s as binary. The README had the instruction that how
you need to paths the existing source bundle with the new one to create
the binaries.
3. We voted on the source files only
4. The nbms were overwritten in the distribution directory and the
updates.xml.gz was patched by hand.
Probably the ugliest part was the actual release of the nbms. In the
future we could create a separate update center for release updates and
ship that configured in the release. I think the new plugin portal
infrastructure probably could help, if that'd support multi tenancy.
On 10/23/19 5:51 AM, Neil C Smith wrote:
> On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga <ge...@apache.org> wrote:
>> Will we really need to go through a vote process for this change?
> IMO, yes - it's still a source change. And that's not quite the only
> change required.
>
> But there are other things we might want to make patches for too.
> This thread was not meant to be specific to that one particular issue.
> We need to work out a process for how we do this in future.
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga <ge...@apache.org> wrote:
> Will we really need to go through a vote process for this change?
IMO, yes - it's still a source change. And that's not quite the only
change required.
But there are other things we might want to make patches for too.
This thread was not meant to be specific to that one particular issue.
We need to work out a process for how we do this in future.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Posted by Geertjan Wielenga <ge...@apache.org>.
The question is though, just for clarity, whether we really do need to vote
at all if (when) we provide a patch soon after the 11.2 release for a fix
to nb-javac, which will mean that only this specific file will need to
change:
https://github.com/apache/netbeans/blob/master/nb/updatecenters/extras/nbjavac.impl/release/modules/ext/nb-javac-13-impl.jar.external
I.e., the URL and fallback URL and hash will need to change in that module
and nothing else.
Will we really need to go through a vote process for this change?
Gj
On Wed, Oct 23, 2019 at 1:19 PM Neil C Smith <ne...@apache.org> wrote:
> On Tue, 22 Oct 2019 at 11:13, Neil C Smith <ne...@apache.org> wrote:
> > I'm wondering whether if we do ship updates, we trigger a new
> > milestone in the release branch, and have a vote on full sources, as
> > per normal. Alongside that we nominate specific module convenience
> > binaries (nbms) to be added to the mirrors / update centre.
>
> Two further thoughts on that -
>
> * we would either need to merge the catalog info to include the new
> modules OR we remove the 11.2/nbms folder completely and link to
> 11.2-update1/nbms ? Second way simpler, but we end up with new build
> versions of all modules.
>
> * currently the distribution nbms aren't signed as far as I know?! What
> are the implications for updates there?
>
> Some thoughts here would be good! How do we best handle this at ASF?
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: [DISCUSS] Handling release updates
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 22 Oct 2019 at 11:13, Neil C Smith <ne...@apache.org> wrote:
> I'm wondering whether if we do ship updates, we trigger a new
> milestone in the release branch, and have a vote on full sources, as
> per normal. Alongside that we nominate specific module convenience
> binaries (nbms) to be added to the mirrors / update centre.
Two further thoughts on that -
* we would either need to merge the catalog info to include the new
modules OR we remove the 11.2/nbms folder completely and link to
11.2-update1/nbms ? Second way simpler, but we end up with new build
versions of all modules.
* currently the distribution nbms aren't signed as far as I know?! What
are the implications for updates there?
Some thoughts here would be good! How do we best handle this at ASF?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists