Doc, I apologize for the top post and breach of netiquette, but it's because I am not going to keep rehashing and reiterating the same thing over and over and over. I'm tired of discussing this, your points are taken and are not going to be dismissed, but I will not keep replying only for you to send back yet another retort. I am focusing on what is best for GNUstep, I've been part of this project for 20 years and it's a labor of love for me.
I'm not replying anymore as I'm ending this thread here at least for me. Thanks, GC On Tue, Mar 8, 2016 at 4:36 PM, Doc O'Leary < [email protected]> wrote: > For your reference, records indicate that > Gregory Casamento <[email protected]> wrote: > > > On Monday, March 7, 2016, Doc O'Leary <[email protected]> > > wrote: > > > > > And yet I see bugs dating back to 2003 that are still unassigned. If > > > someone has taken responsibility for the involved classes/frameworks, > why > > > aren=E2=80=99t these issues being resolved? If nobody is taking > responsi= > > bility, > > > it makes GNUstep a very hard thing to recommend to people. > > > > > > So? So what if they're not resolved? > > So that sends a message. One that is in conflict with your assertion that > people are taking responsibility and/or the idea that GNUstep is > progressing towards some goal. > > > Some of them may have been addressed > > but not marked as fixed in the bug system. > > That’s a problem that should be fixed. Why is there a policy that even > allows this behavior in the first place? > > > Please, if you will, go to the > > gnome big list and let me know if it's empty. You are drawing a strawman > > argument in the sense that you are assuming we don't care because you can > > find bugs which isn't true at all. > > Please don’t conflate the issues by bringing up other projects. Focus on > what can be done better for GNUstep. Do you think best practices really > would say that leaving issues unresolved for 13 years is the way things > should be done? > > It’s not *that* bugs exist, it’s that they are allowed to fester. And, to > my thinking, it all revolves around the core problem that GNUstep has no > core mission statement that sets the context for how the project gets > things done. > > > It's too bad that you disagree. You yourself said that a mission > statement > > needs to be short and understandable. > > No, my argument is more that it should be concise and mindful. And it > should be able to be detailed in a straightforward manner. If you just > wanted to leave it at “Cocoa Everywhere”, I’d be cool with that . . . > but *only* if you actually set out the sub-goals that are involved in > making that happen and how they’d fit together to make the larger mission > a success. Otherwise, it just comes off as so much wishful thinking. > > > Was it not you that mentioned Kennedy? I'm sorry you can't see the > > implications in the statement. Perhaps you should review it and think > > about it at length. If not then I would be happy to walk you through the > > reasoning. > > Please do so, then. My use of Kennedy’s moon shot was *precisely* to walk > you through the difference between the *list of technologies* that are > being used and the *goal* which they are being used to achieve. GNUstep > is heavy on the former and *very* light on the latter. It’s not a proper > mission statement, but I’ll be happy to hear you out if you think you can > contort it into one. > > > The plain truth of the matter is that most cocoa development shops are > not > > interested in porting their apps. I have talked with many and they see it > > as extra overhead they don't need since they feel as though they are > doing > > well enough or, alternatively, they are relying on another cross platform > > environment like Java or something similar. > > But *why*? What is their main complaint that makes GNUstep unsuitable for > the task? It makes no sense to say they’re the target audience, and then > never discuss the reasons why GNUstep is missing the target. My bet is > that, if they were frank about their objections, they’d echo a lot of the > things I’ve been saying for years. Yet GNUstep never seems to make the > changes necessary to be relevant to a larger development community. > > > I pushed for a UIKit > > implementation base on GNUstep to no avail. I also started on an > > implementation of sorts. It was not picked up. > > Stop with the pointless coding. It’s wasted effort until the project > itself has set a mission statement! It makes no sense to “push” for > anything in an unofficial way; an executive decision needs to be made > about what GNUstep *is*, and then all efforts follow from that. > > > It should be mentioned that we are missing a similar opportunity with > > swift. I am currently doing this myself. Those who are capable of > helping > > me are free to join me at any time in the effort. The GNUstep fork of the > > swift repo is on github and is not private. > > You’ll get more people interested if you set Swift support as a specific > sub-goal in the GNUstep mission statement. But, really, I think you need > to retract in order to expand. GNUstep has a lot of cruft side projects > that need to be culled so that you legitimately have a core product that > is useful to a wider audience. Throwing Swift into the mix isn’t going to > attract new developers if they’re not already interested in the other > pieces of Cocoa that GNUstep offers. > > > I fail to see how we should assure them that it is current and accurate. > > Management from the top down would be a good start. Don’t allow the code > to be updated until the documentation if updated, and make sure it is all > done in a way that shows a coherent understanding of what the actual goals > of GNUstep are. > > > Your assertion is somewhat circular in the sense that unless you actually > > try to use it you may not know if it's accurate and indeed we may not > know > > of there is a problem unless someone reports a problem. You cannot > simply > > say "prove to me it's accurate a priori" > > That’s true. As an outside observer, all we can do is look at what you > present. GNUstep presents a lot of old code. Incomplete apps are promoted > as if they’re the project’s greatest achievements. People talk about > little more than coding. You link to documentation that hasn’t been > updated since 2009. A rookie developer might dive in to see what’s really > what, but an experienced developer will look at the hints given and > conclude the project is organizationally a mess. If you think that’s the > wrong conclusion, I would continue to suggest you address the issues that > we raise instead of leading with “So?” responses. > > > I've given you a mission statement and where the project is heading. I'm > > the project lead. I should know, right? ;) > > You should, yes, but do you? And, more to the point, are you really > letting other people know the direction you’re leading them? I still have > no idea if GNUstep *really* has any interest in seeing Cocoa apps being > ported over from the Mac. Do you have plans for any initiative to address > this? > > > I am perfectly willing to discuss this. Most of your time on his thread > > has been devoted to convincing us that we should discuss this amongst > > ourselves. > > People currently involved in the project *do* need to come together and > self-select the goals that they’re looking to achieve. That’s why it is > an ongoing disappointment to me when I see the brogrammer contingent chime > in with calls for nothing but more code. > > > I believe that after all of these posts we would all love to > > actually discuss it rather than discuss and complain about how it's not > > being discussed. By all means.... Please give us an idea of what you > think > > GNUstep should be. The floor on this mailing list is open. Have at it. > > I’ve already discussed many of those things in previous messages. People > seem unwilling to discuss them. So let’s stick with the one I’ve changed > the subject to: setting a mission statement that can be built upon. > > Blurb version: Cocoa Everywhere > > Basic version: > GNUstep is a project to bring great software from the Mac and iOS to > other platforms, like Linux, Windows, and Android. It is also a way > to portably develop software for those platforms using the same > technologies that have turned Apple into a juggernaut over the > past 10 years. > > It should then go into the detail how it breaks down the features (e.g., > GNUstep Base, etc.), limitations (no CoreWhatever, but maybe support of > portability frameworks that allow for support of platform-native > wrappers to accomplish the same tasks). And it should go into specific > initiatives to bring existing apps to GNUstep as well as initiatives to > put GNUstep-first apps on Mac/iOS platforms. Direct statements that are > calls to action rather than just an inventory of code repositories. > > Discuss. Please. Don’t just dismiss. That’s all I’ve been asking for. > > -- > "Also . . . I can kill you with my brain." > River Tam, Trash, Firefly > > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
