Re: Apache-Netbeans-9.0-MacOSX

[Eduard Karel de Jong]

I's be available to use my Mac mini server as slave.

Also, I did improve on the script to wrap NB in an Mac app bundle that 
was announced a couple of days back. I provided my updates on GitHub to 
the author, who hasn't responded yet.

Would it make sense to have that script be integrated in to our build tools?
--
Eduard

Emilian Bold wrote:

I also have macOS machines I could use here. I just don't know how to hook them 
up as official Apache NetBeans build slaves.

--emi

‐‐‐ Original Message ‐‐‐
On 7 August 2018 3:17 PM, Jim Jagielski  wrote:


If we lack the slaves, I can sign up to do the community builds, as I do for 
AOO.


On Aug 3, 2018, at 1:38 PM, Emilian Bold emilian.b...@protonmail.ch.INVALID 
wrote:
We have an existing JIRA issue for this, the author should also create a GitHub 
PR.
Making the DMG is indeed quite nice. I also have a 20 line shell script to do 
it for NEXTbeans Retina.app
The problem next is pushing this to infra, adding a builds task and getting mac 
build slaves for Jenkins.
--emi
‐‐‐ Original Message ‐‐‐
On 31 July 2018 4:42 PM, Jim Jagielski j...@jagunet.com wrote:


Thank you!
Yes, being able to use your script in order to create community builds
of NetBean would be a major help! Even better, as you say, would be
it being donated to the ASF to allow it to be bundled with the project
as well. Even though it is licensed under the ALv2, and we could just
"fold it in", we normally do not use code unless the copyright
holder of the code is OK with us doing so.


On Jul 30, 2018, at 1:49 PM, Ahmed Alawy alawy.ah...@gmail.com wrote:
Good Morning,
I was giving this email address by Emilian Bold, on Twitter. It seems that
he's suggesting that this package could be included in the dev/release
process of your product.
It was a package that I put together to run netbeans, as I found it quite
annoying to have to traverse to the bin directory to run it, while I can
click XCode, Eclipse or any similar app.
I am working on providing a shell-script that will create this package;
sorta automating the packaging process now that I know how to build it
manually. Once it's ready I will make it available on the same github link.
Please let me know what I need to join/assist in making this MacOS part of
the netbeans release process.
Thanks for taking the time to read my email.
Ahmed

--
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [ANN] Closing the NetBeans Logo Contest

[Eduard Karel de Jong]

logo 2: +1
--
Eduard

Antonio wrote:

Ipso facto.

On 01/03/18 13:32, Geertjan Wielenga wrote:

I agree with John McDonnell -- would be good to have a vote thread, I
think, like for voting on a release, enabling everyone to vote for a
specific logo.

I suppose that would mean one such thread on @users and one on @dev.

Gj

On Thu, Mar 1, 2018 at 1:23 PM, John McDonnell 


wrote:

We should create a vote thread here, or on users.  This is 
consistent with
normal apache votes.  All it needs is a link to the confluence page 
to show

the images and their option numbers.

It avoids everyone having to have edit writes on the confluence just 
for a

vote.

Regards

John



On 1 March 2018 at 12:21, John Kostaras  wrote:


It's not clear where do we have to add our vote: in confluence
or
in jira ?

I vote for option 2, too.

Regards,

John.

On 1 March 2018 at 13:16, Neil C Smith  wrote:

On Thu, 1 Mar 2018 at 12:08 Peter Steele  
wrote:


That means you need to have an account that is approved for 
editting.




Good catch!  Do we really want to restrict voting to wiki 
editors?  Or

to

dev@?  Or to users@?

Personally, I'm in favour of at least having a thread on here

specifically

for voting, if not one at users@ too.

Best wishes,

Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding -

www.praxislive.org










-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: The logo, once and for all? (was AW: Merged to master (was Re: A NetBeans website proposal))

[Eduard Karel de Jong]

Indeed, the icon without typgraphy should be the item to vote upon this 
time.
The next discussion and a subsequent vote should be on the elements that 
we want to present in the typography, for instance:

-the word "apache"
-the feather
-a 'badge' with "IDE"  (with a possible alternate badge for the 
framework, like "AFW".
An other question is if the words "Net" and "Beans" should be with 
distinct typography.


Cheers
Eduard



Antonio wrote:

I'd say the icon without the typography.

Cheers,
Antonio

On 26/02/18 12:16, Neil C Smith wrote:

On Mon, 26 Feb 2018 at 11:06 Antonio  wrote:


To end up the logo discussion once and for all I propose:

- Announcing closing the contest within a few days.
- Announce a voting in the mailing list, as per the Apache way.



Sounds good!

Can we also clarify what we mean by logo though?  Are we at this stage
literally looking for the replacement for the cube icon, without any 
text /

typography?

Because currently the blue logo has 6 or 8 votes depending on what we 
mean.


Best wishes,

Neil



-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

beta delivery and beyond WAS: Users first (was Re: Pull requests need to be reviewed)

[Eduard Karel de Jong]

I can't agree more with Antonio and Geertjan: as a community we need to 
keep our eyes focussed on the goal: delivering a superior IDE to 
developers. And doing so in a timely fashion.


My earlier suggestions about voting to move forward with a beta release 
intended to support keeping that focus. From the many things that could 
be improved in the code, and with such a large code base and extensive 
functionality there alway will be a lot of these, we need to identify 
which will be essential to realise before getting to the next stage of 
release.


As an open source project we need to find a balance between on one side, 
sustaining a vibrant community, where many are engaged and feel 
appreciate for their various roles, and in efficiently making 
decissions. To be specific, democracy is great for the former but may at 
times be too slow and not explicit enough for the latter.


After a community decision to have a beta release we will need a small 
committee to rank any changes to code and functions that should be 
realised before the next stage. In my view Geertjan, possibly together 
with a couple of others should have that task, the task of identifying 
these essential additions to the beta code base. The  input for the 
decision on essential PRs should be, primarily, in my proposal, from the 
issues provided accompanying the vote to go to beta. And, next to 
setting the priorities that small group should set a date by which the 
next release stage should ideally be ready.


With that date for a next release known, any PR that was not qualified 
as a priority and for which some members in the community had the energy 
to address the issue in time could still be considered for integration. 
Such additional PRs could be required to be ready some time before the 
times set for the essential ones to give time for deciding on them 
without interfering with the main line of the delivery schedule.


A further thought on the small committee that takes those decisions 
about timely moving from beta to the next stage in the release, in 
addition to a small core of one or two people, members of the community 
could self nominate for membership thereof. To that end the size of the 
committee, let's call them the "release shepherds' has a maximum size, 
7, or so, and self nomination happens in two stages: first, interest to 
be involved as release shepherd is indicated on the ballot response, 
secondly, if there are more candidates, those interested discuss amongst 
themselves who of them will be a shepherd this time. As background, I 
have very good experience with self nomination for the governance of  a 
very long-running (30+ years) of a no-conference i participate in 
(Consultants' Camp ).


In summary, the idea i developed here,  is to structure a vote for beta 
release to have three parts:

— up/down/don't care (=+1/-1/0), this is required to be a real vote
-—One or more PRs the voter considers essential to integrate before the 
next stage. Optional with +1 vote,  required with a -1 vote.

-—Self nomination as shepherd, optional.
The idea to require at least one PR with a negative vote is borrowed 
from international standardisation with ISO. The idea is that addressing 
these issues would change the vote to, at least, don't care (=0).
These rules should apply only to a vote for a beta release at that's 
when we, as a community, decide it's really ready to release, so that 
release should happen sooner rather than later.


I realise all this is getting a a bit more than 2¢. Sorry about that. At 
this point in time, I don't have much time to contribute to the coding 
effort, yet I like to support NB as it moves into open source, by 
sharing some of my experiences with open organisations and democratic 
decisions in standardisation and in (city) politics. These ideas may be 
worth a dedicated thread of discussion. Anyway, there's no harm in 
experimenting and adjusting based on what we learn.


Cheers
Eduard


Antonio wrote:

Hi,

My 2 cents: I agree with Geertjan: I think we should concentrate our 
efforts in the best NetBeans 9 we can build for users. There're many 
important things to do, ranging from the website to the jdk-javac 
branch. And many new tools to control, ranging from the wiki to the 
very slow JIRA issue tracker.


I think we should stay focused in those things that worry users, for 
the benefit of the users, and leave those code-cosmetic, internal 
changes for later on. After all NetBeans users deserve the best IDE we 
can build, and it does not really matter to them if we're improving 
the readability of ternary operators or if we're replacing for loops 
with the Streaming API.


NetBeans is the second Apache project by size (as per [1]), with more 
than 5.5M lines of code. Making those millions of lines of code more 
readable & pretty may be a perfect academic case study, but spending 
our efforts on those areas won't make our users more happy.


Cheers,

Re: AW: Pull requests need to be reviewed

[Eduard Karel de Jong]

To add my 2¢ to this discussion:

To make these ideas more concrete, in my view, the result of the current 
vote would be that at its closing a clearly marked branch is created 
that implicitly freezes the feature set. A voter, when submitting a vote 
can propose one or more PRs that should be included  with the 
understanding that such a PR should address a bug. Bug should be taken 
as not only addressing reported code failures but also glitches and 
confusion in user facing functions. Indicting multiple PRs their order 
could be interpreted as a priority.


A rule like this could be codified somewhere  and then included when 
calling for a vote. I haven't checked if other projects have something 
like this, though, and there may be better ways to get the kind of 
process we need.


Cheers
Eduard

Christian Lenz wrote:

If we are now at a Feature freeze, we should create a release/nb9 branch to 
make it clear, no new Features there and some documentation and so on. 
Everything else, so other PRs can still be handled in develop.

Von: Geertjan Wielenga
Gesendet: Freitag, 12. Januar 2018 11:41
An: dev@netbeans.incubator.apache.org
Betreff: Re: Pull requests need to be reviewed

Yup, makes sense to me, Neil. We need to make these things explicit and
indeed will take a look at the related NetBeans processes, though I agree
however we’re looking at it we are now at a stage of feature freeze and
should incorporate bug fixes only, ideally as part of the NetCAT phase post
Beta — making it all the more urgent that everyone tries out the Beta
artifact and specifies their vote on it in the vote thread.

Gj

On Friday, January 12, 2018, Neil C Smith  wrote:


On Fri, 12 Jan 2018 at 08:04 Geertjan Wielenga<
geertjan.wiele...@googlemail.com>  wrote:


I think we need to set up guidelines — e.g., a PR must be connected to an
issue; a PR must solve a problem and not be cosmetic only; etc.

I’d advise looking at pull/3 by Chris instead.


I like Chris' PR, and see the benefit of it ... but, within those
guidelines are we going to have the concept of feature freeze?  In my
opinion, if we're in beta vote phase, we should also only be accepting bug
fixes.  In which case, I'd be tempted to push that back to the next point
release?

Out of interest, what were the old NetBeans policies around feature
freezing / release planning?

Best wishes,

Neil



--
Neil C Smith
Artist&  Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: testing footers...

[Eduard Karel de Jong]

It works for me! (using Postbox on Mac)
--
Eduard

Neil C Smith wrote:

On Mon, Dec 18, 2017 at 12:09 PM Geertjan Wielenga<
geertjan.wiele...@googlemail.com>  wrote:


That would be perfect -- others on this list, please also comment,
especially if for whatever reason you've been trying to unsubscribe and
still not succeeding, does the above footer help?



I'd be tempted to add some form of this (from
https://www.apache.org/foundation/mailinglists )


After you send the subscribe or unsubscribe request, the list manager will
send you a confirmation e-mail in reply. You must reply to this e-mail to
complete the process. If you have not received the confirmation request,
check that it has not been marked as spam.


The need for the confirmation email, which has a lot of potential to be
marked as spam, is annoying and potentially confusing.  Is email delivery
suspended pending that?

Best wishes,

Neil