Hi, Le 2015-05-31 04:35, David Morris a écrit : > On Sat, May 30, 2015 at 9:46 PM, J G <jmzho...@gmail.com> wrote: >> Hi David, >> >> What do you mean full control? As far as it remains GPL and GI agrees, >> I am fine with that. :) > > Yes, it would stay GPL. Full control is probably the wrong way to > state it. Here is what I mean: I'm a big believer in one person > providing direction for a software project and designing the overall > architecture. My experience is it always leads to a better end > product.
Thanks for the proposition to continue the mrxvt project. I have only one concern about the form, this is that you are asking to get "full control" even before having checked at the code. By "full control", I guess you mean you want to be considered the new official upstream (since you can as well make a fork and you'd be in full control there). Now don't get me wrong. Same as everyone, I'd be far more than happy to get a new maintainer who actually make this project alive again. But the Free Software way is that you'd send us a few patches and they'd be good quality. Really the "step" is not very high. As you know, contributions are nearly non-existent for years. It will be very easy to get all our agreement to take the project over with a few good patches. But speaking about getting full control before even having sent a single patch feels a little like putting the cart before the horse to me. > I have a great deal of respect for mrxvt and all of you who > created it (it is, after all, my favorite terminal). At the same > time, I want to know that if I take over the development lead for > mrxvt that I am making those decisions, not fighting with other > developers who are no longer active on the project (yay GPL). If I > don't have that freedom, I would either fork mrxvt into a new project > of my own or not work on it at all. Well if really the normal way of contributing (sending patches which get accepted and in the tree first) is so unbearable to you, forking mrxvt and doing great things with it does not seem like a bad thing to me. If I see that you go exactly towards the vision of mrxvt we have and improve it, then I'd be happy to put my vote to give you the control to mrxvt (hence merge your code into our tree, or simply we could put a disclaimer on our website that you are to be considered the "new mrxvt", using the same name if you want). This won't be the first case in Free Software history that a fork is merged back into upstream (or take its place). But once again, just coming and say "give me the control" without showing exactly what you want to do, I'm really not fond of it. I will let this happen if all other developers are in favor of it, but that's not my vote. Also what you call "fighting", I call it "discussing". I have patches in several dozens of Free Software, from GIMP to Blender, Firefox, gettext, fontconfig, glib, etc. Except for a few (like GIMP), in most these are just very few patches. And when I propose my patch, people often discuss a feature or a fix, ask me to do it another way, and so on. Sometimes for a small patch, it is quick, other times it may take quite some time to be accepted upstream (sometimes it even gets refused). But that's ok. That's normal even. You can't expect that everybody agrees with you all the time, and everybody has to do compromises. But I barely see myself asking for "full control" on the mailing list the first day. Now really, don't take it the wrong way. Maybe you are a genius developer, and as soon as I'll see your first patches, I would say "you have to be the maintainer". And I will gladly say so if it happens that you first changes are very good. Also I'm not the current maintainer. My opinion does not really matter as much as GI and Jimmyzhou who were here much before me, but I still wanted to state my feeling on this. > That said, advice, input and coding help is always appreciated and it > sounds like you and I likely have some similar views. > > Code cleanup and moving to a more object oriented design would be high > on my list of priorities. I have no need to use C++ (C is just fine > for OO design), but would consider it if I think it would be > beneficial and I have the commitment to the project for such a > transition. > > Keeping mrxvt as much self contained as possible is worth considering, > thank you for that thought! If I do start work on mrxvt I'd like to > hear more of your view on this after I've learned the code. The only > reason I was wondering at all originally, is it occurred to me to > wonder what would it take to modify mrxvt so that it could also be > compiled as a native OSX terminal app. Though it occurs to me now, it > might be worth at least looking into if it would simplify the code > enough to be worth the tradeoff. Same as others, I'd be in favor to keep mrxvt as self-contained as possible. Not because I don't like dependencies and want to reinvent the wheel, but because otherwise there is not much point of mrxvt compared to other existing (and very good!) terminal emulators. Also it worked well until now this way. I think most people want UTF-8 as higher priority. I doubt that passing to GTK+ or adding other dependency be considered as any importance to users, me included. Thanks. Jehan > Thank you for your thoughts! > > David > > > > > >> I started mrxvt project based on rxvt 2.7. After it was in a >> reasonably >> shape, GI took active development and added a lot of new features. I >> do >> not know much about the mrxvt05utf8 branch. My development was mainly >> in mrxvt05b branch. Feel free to ask questions about the design, I >> will >> try my best knowledge to answer - though my memory about it is fading. >> >> Later, I thought about code cleanup. Most notably: >> >> . Re-organize the code to make it more object-oriented. When I wrote >> it, I did not have much experience on object-oriented design. So it >> was kinda messy. But I did not want to use C++. Anyway, it’s just a >> personal taste. Feel free to try if you have a strong opinion towards >> C++. >> >> . Cleanup input handling. There are several input source in mrxvt: >> X event, and file descriptor of tty devices. The current code is >> very messy, and I always have a feeling that something is probably >> wrong in handling tty input - meaning input from one tty can possibly >> leaks into another tty. >> >> About library, I’d like to keep it as simple as possible. That said, >> I do not want to introduce dependency on additional libraries without >> a careful consideration. My philosophy towards mrxvt is to make it as >> much self-contained as possible. >> >> I do not have an opinion on hosting. As far as there is an official >> place to host the project, I am fine. >> >> Best regards, >> Jingmin >> >> >> On May 30, 2015, at 14:40, David Morris <otha...@othalan.com> wrote: >> >>> On Sat, May 30, 2015 at 12:42 PM, <gi1...@gmail.com> wrote: >>>> On Sat, May 30, 2015 at 10:32:23AM -0400, David Morris wrote: >>>> >>>>> Does anyone have an overview of the changes needed to complete utf8 >>>>> support? I've been considering a new software project and I might >>>>> be >>>>> interested finishing it up, or perhaps even taking over all active >>>>> development. If I do either, I'd also migrate the code to a >>>>> different >>>>> source control platform. >>>> >>>> Jehan's the guy who wrote an alpha UTF-8 branch! I've tried it -- it >>>> works, but crashes often. (And sometimes the display is borked.) >>>> >>>> I don't know the specifics about displaying UTF-8 though. Hopefully >>>> Jehan will write back soon with a good clear outline that will sell >>>> you >>>> on it. I'd love it if you finished the UTF-8 support and or took >>>> over >>>> development. >>> >>> I took a quick look around just to evaluate the scope of the project >>> if I were to take over. First, some questions: >>> >>> If I did take over active development, would complete control be >>> relinquished to me? I would only do this if I have full control of >>> the project. I would of course be happy to get any input, advice and >>> coding help. >>> >>> What is the history of mrxvt? Did the code originate from rxvt? Or >>> was it developed separately? If I have questions about the design >>> decisions, is there someone to ask? >>> >>> What is the relationship between code in the branch mrxvt05b (the >>> main >>> development branch) and mrxvt05utf8? How much code was pulled in >>> from >>> the utf8 branch? I can analyze each, but it'd be easier to get an >>> overview if anyone still remembers. >>> >>> The code looks generally reasonably clean and well commented, but >>> were >>> any major changes considered? Such as code cleanup, porting to C++, >>> changing to different GUI libraries, etc.? >>> >>> Source code hosting: I looked at all of the alternatives and the one >>> that stands out to me is GitLab. If I move the repository, that would >>> be my first choice. >>> >>> SVN to GIT: I did a quick test using svn2git and it is quick & easy. >>> >>> Sourceforge Bugs, etc which need to be reviewed & transferred if the >>> hosting is changed. These would eventually have to be moved over to >>> the new system, but because of the lack of active development for a >>> long time now I don't see any rush to go through these. Patches >>> should probably be evaluated first. >>> 33 open bugs >>> 6 open support requests >>> 17 open feature requests >>> 6 open patch submissions >>> >>> The wiki would need to be ported over. This should be done before a >>> new release but is probably not necessary before then. >>> >>> David >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Materm-devel mailing list >>> Materm-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/materm-devel >>> mrxvt home page: http://materm.sourceforge.net >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Materm-devel mailing list > Materm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/materm-devel > mrxvt home page: http://materm.sourceforge.net ------------------------------------------------------------------------------ _______________________________________________ Materm-devel mailing list Materm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/materm-devel mrxvt home page: http://materm.sourceforge.net
