Re: Apache-Netbeans-9.0-MacOSX
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
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 <mcdonnell.j...@gmail.com> 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 <jkosta...@gmail.com> wrote: It's not clear where do we have to add our vote: in confluence <https://cwiki.apache.org/confluence/display/NETBEANS/ Apache+NetBeans+Logo+Contest>or in jira <https://issues.apache.org/jira/browse/NETBEANS-145>? I vote for option 2, too. Regards, John. On 1 March 2018 at 13:16, Neil C Smith <neilcsm...@apache.org> wrote: On Thu, 1 Mar 2018 at 12:08 Peter Steele <steeleh...@gmail.com> 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))
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 <anto...@vieiro.net> 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
Re: The logo, once and for all? (was AW: Merged to master (was Re: A NetBeans website proposal))
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 <anto...@vieiro.net> 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)
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 <http://www.consultantscamp.org>). 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
Re: AW: Pull requests need to be reviewed
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<neilcsm...@apache.org> 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...
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