Re: [Geany-devel] Git Switch (again)
On 05/09/11 17:16, Colomban Wendling wrote: Maybe, need to check but might not be that painful (BTW, don't GitHub offers a SF BT import feature? :D) It wouldn't surprise me if it does have such a feature (or script available somewhere). Alternatively, I could probably hack something together in Python using this[1] and this[2]. [1] https://sourceforge.net/export/sf_tracker_export.php?group_id=153444&atid=787791 [2] http://develop.github.com/p/issues.html Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
Le 10/05/2011 01:34, Matthew Brush a écrit : > On 05/09/11 11:12, Colomban Wendling wrote: >> Le 09/05/2011 19:35, Jiří Techet a écrit : > >>> >>> I'd say that VCS migration and bug tracking system migration should be >>> done separately and independently. Migration of the bug tracker is a >>> lot of work while migration to git is quite easy. I'd also be rather >>> cautious before moving the bug tracker to GitHub. At the moment they >>> are offering hosting of open source projects for free but there's no >>> guarantee it will be like that in the future as well. This is no >>> problem with the git repository if they get evil - you can always >>> upload the repository somewhere else and update a few links on the >>> geany's home page. However with the bug tracker it would be a much >>> more painful process. >> >> Well... this makes sense, but having the but tracker on SF and the code >> on GitHub seems a bit like a suboptimal option -- though since SF don't >> really link bug tracker and VCS maybe it'd not really change anything. > > From what I can tell, the majority of the bugs in the SF tracker are > either closed, open but will never get resolved or no longer apply to > current versions, so I don't know how much of a big deal it would be to > start moving away from it, of course always leaving it (possibly > read-only?) for reference. Maybe, need to check but might not be that painful (BTW, don't GitHub offers a SF BT import feature? :D) >> But the point on the possible future of GitHub is important IMO. if we >> have no guarantee for the long-term viability -- and when I read you I >> read "I'd not be really surprised if it happened" --, do we really want >> to use this? I mean, if we need to switch to another official repo next >> year because GitHub decided not to continue to provide (free) hosting >> for us, it'd not be really good. > > Speculating on the future of any of the project hosting sites is just > that, speculation. They have different business models, like SF with ad > revenue, GitHub with private paid accounts, Gitorious with extra > services (and probably $ from Nokia), and Google Projects with Google's > plan for total world domination. > > If I had to make a guess, I'd say it would be more likely for SF to go > belly up due to lousy services, mass exodus to better project sites and > it not being financially worthwhile for GeekNet. > > Put simply, AFAIK, none of these projects sites offer a guarantee that > they will not shutdown, go paid only, or otherwise change their > services, so I don't think speculation should be a primary factor in > deciding on a project site. Agreed as said in another mail, apart that I doubt SF will really die, just maybe become even more crappy by the years. >> I haven't either checked the other sites (Gitorious, ?) deeper, maybe >> they are good candidates if we don't want the BT functionality? don't >> know -- apart that I already have and account on Gitorious and wasn't >> scared by their policy. > > I can't say I'm personally opposed to Gitorious, but to me it just seems > like a stripped-down version of GitHub, missing lots of the cool > features. Of all the project hosting sites I've used though, the only > two I really dislike are SourceForge and Launchpad followed farther by > Google Projects. Well, again, I have no real opinion on this, apart that yeah, GitHub *seems* (haven't tested it) to have more cool features. I was suggesting something else only because of the speculations about GitHub's future ;) Anyway, I think we should wait for Nick's opinion, and probably again Enrico and Frank ones about the BT stuff. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
Le 10/05/2011 00:43, Lex Trotman a écrit : >> But the point on the possible future of GitHub is important IMO. if we >> have no guarantee for the long-term viability -- and when I read you I >> read "I'd not be really surprised if it happened" --, do we really want >> to use this? I mean, if we need to switch to another official repo next >> year because GitHub decided not to continue to provide (free) hosting >> for us, it'd not be really good. > > Well, that risk exists for any free hosting service, even Sourceforge > could go broke, as Jiri says easy for DVCS, especially if there is an > up to date mirror, hard for bugtracker. Of course; DVCS are really helpful in this kind of situations (and many others :D). But if we keep the idea "everything can go by", maybe moving BT too to GitHub wouldn't be more of a problem than leaving it on SF (apart the actual move required); and I believe that having the BT integrated with the VCS provides some comfort (even just the auto-close feature). >> But yeah, switching to Git doesn't even mean going away from SF (though >> it couldn't be bad :D), they also offers Git repositories. Just no fancy >> around like merge requests, reviews & co. > > I didn't think they allowed anyone to create a public clone, I think > that is a required feature to get more involvement, anyone can say > "I'm going to try this..." and the community can see it and provide > guidance and testing. No I don't think they have any fancy around the repo; it'd just make my own life easier by using true Git :D Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Newsletter issues #2 reaching target line
Le 10/05/2011 01:54, Lex Trotman a écrit : >>> Now done. Sorry for the long delay, and thanks again for the hard work! >> >> Cool, so we don't need to change the newsletter at this point ;) >> > > Hey, new workflow, get a new feature described in the newsletter and > then it will be added to Geany so the newsletter isn't wrong :-) Don't even think about it :D ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Newsletter issues #2 reaching target line
On 05/09/11 16:54, Lex Trotman wrote: Now done. Sorry for the long delay, and thanks again for the hard work! Cool, so we don't need to change the newsletter at this point ;) Hey, new workflow, get a new feature described in the newsletter and then it will be added to Geany so the newsletter isn't wrong :-) Priceless. Literally LOL'd. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Newsletter issues #2 reaching target line
>> Now done. Sorry for the long delay, and thanks again for the hard work! > > Cool, so we don't need to change the newsletter at this point ;) > Hey, new workflow, get a new feature described in the newsletter and then it will be added to Geany so the newsletter isn't wrong :-) Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] hex mode
On 10 May 2011 00:33, Johann SAUNIER wrote: > I am using Scite every day at work to open files containing NULL characters > (that Geany can't open). Scite is based on Scintilla, and it doesn't stop at > the first NULL character. I guess it should be possible to open binary files > in Geany too ... > Depends on the interface between Scite and Scintilla, most of the functions from Scintilla accept null terminated text so they stop. There are a few that use lengths and will accept NUL characters. It would mean re-writing all the Geany interface to Scintilla to use only those functions, but for little gain and much pain (probably a period of many bugs). In general reading binary files isn't a common part of development workflow (or we would have lots of requests for it) so adding it to Geany would not be a priority. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
On 05/09/11 11:12, Colomban Wendling wrote: Le 09/05/2011 19:35, Jiří Techet a écrit : I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process. Well... this makes sense, but having the but tracker on SF and the code on GitHub seems a bit like a suboptimal option -- though since SF don't really link bug tracker and VCS maybe it'd not really change anything. From what I can tell, the majority of the bugs in the SF tracker are either closed, open but will never get resolved or no longer apply to current versions, so I don't know how much of a big deal it would be to start moving away from it, of course always leaving it (possibly read-only?) for reference. But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read "I'd not be really surprised if it happened" --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good. Speculating on the future of any of the project hosting sites is just that, speculation. They have different business models, like SF with ad revenue, GitHub with private paid accounts, Gitorious with extra services (and probably $ from Nokia), and Google Projects with Google's plan for total world domination. If I had to make a guess, I'd say it would be more likely for SF to go belly up due to lousy services, mass exodus to better project sites and it not being financially worthwhile for GeekNet. Put simply, AFAIK, none of these projects sites offer a guarantee that they will not shutdown, go paid only, or otherwise change their services, so I don't think speculation should be a primary factor in deciding on a project site. But yeah, switching to Git doesn't even mean going away from SF (though it couldn't be bad :D), they also offers Git repositories. Just no fancy around like merge requests, reviews& co. Still leaves the problems of slow services (though Git would probably be faster), crappy web interface, lack of forking (and others you mentioned) and having public forks attached to the project, crappy bug tracker, etc. I haven't either checked the other sites (Gitorious, ?) deeper, maybe they are good candidates if we don't want the BT functionality? don't know -- apart that I already have and account on Gitorious and wasn't scared by their policy. I can't say I'm personally opposed to Gitorious, but to me it just seems like a stripped-down version of GitHub, missing lots of the cool features. Of all the project hosting sites I've used though, the only two I really dislike are SourceForge and Launchpad followed farther by Google Projects. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
> But the point on the possible future of GitHub is important IMO. if we > have no guarantee for the long-term viability -- and when I read you I > read "I'd not be really surprised if it happened" --, do we really want > to use this? I mean, if we need to switch to another official repo next > year because GitHub decided not to continue to provide (free) hosting > for us, it'd not be really good. Well, that risk exists for any free hosting service, even Sourceforge could go broke, as Jiri says easy for DVCS, especially if there is an up to date mirror, hard for bugtracker. > > But yeah, switching to Git doesn't even mean going away from SF (though > it couldn't be bad :D), they also offers Git repositories. Just no fancy > around like merge requests, reviews & co. I didn't think they allowed anyone to create a public clone, I think that is a required feature to get more involvement, anyone can say "I'm going to try this..." and the community can see it and provide guidance and testing. > > I haven't either checked the other sites (Gitorious, ?) deeper, maybe > they are good candidates if we don't want the BT functionality? don't > know -- apart that I already have and account on Gitorious and wasn't > scared by their policy. > It really wouldn't be hard either, the whole "switch" be done in probably 10-15 minutes, maybe 1-2hrs to wait for the history to be imported. There's no real reason it needs to be a big deal either, we could test out another project site and keep it the way it currently is still with not much extra effort, just someone/somescript needs to push to the new project page after committing to SVN. Basically all it would take beyond that is for one of the founders/core members to take some time to setup an account and push the code. >>> >>> Before moving all main commiters should agree (e.g. Nick and Enrico), >> >> Enrico doesn't care, you like it, so the one who will have to decide >> is Nick :-). > > Yep ^^ > >>> but I think the creating par would not be the real problem. As discussed >>> further later in thread the problem is more setting up correct hooks to >>> keep all repos up to date. >> >> But those hooks were meant to be used to have a git mirror on GitHub >> if there's no VCS switch (mirroring the current git mirror of SVN). I >> don't see any point in having multiple git mirrors if you switch to >> git (well, actually everybody's personal clone would be such a >> mirror). > > I think we shouldn't drop e.g. the git.geany.org mirror if we can keep > it, so we'd need a hook in the official repo to push to it or whatever. > > Cheers, > Colomban > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [RFC] Plugin Template
Le 04/05/2011 02:20, Matthew Brush a écrit : > On 05/03/11 05:42, Colomban Wendling wrote: >> I don't think the template is really useful, apart maybe for >> Makefile.ams and wscript_* (though I don't know exactly what's in the >> later), but I think that for the other files a tutorial is just enough >> and probably even better: >> > > Maybe I used the wrong word or you misunderstood what I mean by > template, I don't mean "download this and your good to go", I mean > "download this, edit the boilerplate files as per the comments/examples > in them (and described in a tutorial), and you've got a good start". > > [...] Still not really convinced that it's really useful, but you seem to know why you think it is regarding how you defend it :D And I won't prevent anyone from adding this, why not if it has users. >> * configure.ac is a bit pointless since we talk about geany-plugins >> integration ^^ > > Not pointless if you want to build your plugin inside the checked-out > directory, as would be described in the tutorial (before being added > to the geany-plugins project). Hum, the thing is that for a "newbie" configure.ac generally looks like dark magic or at least weird stuff, so you'll need to explain how it works and what to modify, but it won't be valid for real G-P plugin, because the G-P's configure.ac has a quite sophisticated layout. Or you would copy & paste the G-P specific M4 macros? (GP_*) Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SplitWindow Windows support/fixes
Le 09/05/2011 20:25, Oliver Krystal a écrit : > Just tried this with the nightlies on windows, and it doesn't crash or > anything like that. None off the right click functions work in the > split off window. Thanks for testing! Actually it wouldn't crash, but have a really weird display. If you didn't notice anything, it's OK :D And yeah, currently the second editor is a lousy version of the Geany's one, with many features missing (though many less since Matthew gave it some love). Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SplitWindow Windows support/fixes
Just tried this with the nightlies on windows, and it doesn't crash or anything like that. None off the right click functions work in the split off window. On 5/9/2011 1:01 PM, Enrico Tröger wrote: On Mon, 09 May 2011 15:35:00 +0200, Frank wrote: Am 09.05.2011 15:27, schrieb Colomban Wendling: Le 08/05/2011 23:18, Matthew Brush a écrit : On 05/08/11 10:08, Colomban Wendling wrote: just need to re-apply the commits: http://git.geany.org/geany/commit/?id=757654e14b40d85c95c50ab422e3bcd63fa7fd29 http://git.geany.org/geany/commit/?id=1788dfa8dc6ba106a16069cf4ca79d3ee2a5533f Yep, that should do it. Applied again. I tested under Linux, and it works OK, no more selection problems, nor weird cursors. I haven't tested on Windows, but I guess that nothing changed on this side since Enrico tried it last time? Though if somebody have the time/courage/will to test it on Windows again, it'd be great :) Will give it a try once a Windowsbuild with this change is available. http://nightly.geany.org/win32/ Have fun. (I manually started the nightly build to get this new version into the Windows build. I almost finished reworking the nightlies system and will announce it once it's all running again.) Regards, Enrico ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Planning bugfix release 0.20.1
Le 08/05/2011 17:20, Enrico Tröger a écrit : > On Wed, 4 May 2011 22:53:18 +0200, Enrico wrote: > >> Hi, >> >> I'd say let's make a 0.20.1 bugfix release soon. >> So we can release the fixes made since the 0.20 release for users. >> >> >> If no one beats me by time, I'll create a 0.20.1 branch based on the >> 0.20 tag on Sunday and then we can backport relevant fixes. > > Branch created, happy backporting :). > I'll try to backport my (very few) fixes within the next days. > > Colomban, Nick, would you backport your changes yourself? Done for my owns. I didn't backport the following fixes because I though they maybe are either too big or have other "flaws", but if you think I should I can do it: * "Properly convert template files to UTF-8 on loading" [1] that depends on "Move document encoding conversion with BOM support to encodings.[ch]" [2] * "Avoid triggering autocompletion on PHP open tags (closes #3199442)" [3] because it was quite controverted [4] (haven't had the time/will yet to investigate it further) Cheers, Colomban [1] http://git.geany.org/geany/commit/?id=7bb3e8c32d1fc66d51645f7143e433d6ae13b7a8 [2] http://git.geany.org/geany/commit/?id=ec13c7d8ed6a861e389e7b0c5b77b31c3d80aca4 [3] http://git.geany.org/geany/commit/?id=2a73a0e77a9aa097890e5df1855bf9f3fcec8a37 [4] http://lists.uvena.de/pipermail/geany-devel/2011-April/004474.html ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
Le 09/05/2011 19:35, Jiří Techet a écrit : > On Mon, May 9, 2011 at 16:16, Colomban Wendling > wrote: >>> - Effort required to move the project >> >> That's the big part! > > Not that bad if you move the repository only to GitHub - see below. Right. >>> - No need to maintain changelog and authors files >> >> That's not true. Our ChangeLog don't contain each and every commit, nor >> necessarily the whole commit message. >> >> Although I don't personally second such ChangeLog (mostly because we >> have to maintain it and it's the biggest source of conflicts), I >> understand the point of Nick and Enrico to keep it, and won't start >> discussion on this again. > > Could you point me to the discussion? I've missed that one. (I too > find a manual-maintained ChangeLog to be too much effort with too > little gain.) Hum, seems it actually was about Geany-Plugins ChangeLog... anyway, here's the archive: http://lists.uvena.de/pipermail/geany-devel/2010-November/003401.html >>> Obviously I'm not suggesting that the SourceForge project page is >>> deleted, just switching the main development activity to elsewhere. We >>> could have a git/svn mirror over at SourceForge still, and even keep >>> their bug/feature tracker, though I can't see why, since it's pretty lousy. >> >> The difficult part is moving bug tracking I guess. If we end up having 2 >> bug trackers it'd become quite a pain :/ > > I'd say that VCS migration and bug tracking system migration should be > done separately and independently. Migration of the bug tracker is a > lot of work while migration to git is quite easy. I'd also be rather > cautious before moving the bug tracker to GitHub. At the moment they > are offering hosting of open source projects for free but there's no > guarantee it will be like that in the future as well. This is no > problem with the git repository if they get evil - you can always > upload the repository somewhere else and update a few links on the > geany's home page. However with the bug tracker it would be a much > more painful process. Well... this makes sense, but having the but tracker on SF and the code on GitHub seems a bit like a suboptimal option -- though since SF don't really link bug tracker and VCS maybe it'd not really change anything. But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read "I'd not be really surprised if it happened" --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good. But yeah, switching to Git doesn't even mean going away from SF (though it couldn't be bad :D), they also offers Git repositories. Just no fancy around like merge requests, reviews & co. I haven't either checked the other sites (Gitorious, ?) deeper, maybe they are good candidates if we don't want the BT functionality? don't know -- apart that I already have and account on Gitorious and wasn't scared by their policy. >>> It really wouldn't be hard either, the whole "switch" be done in >>> probably 10-15 minutes, maybe 1-2hrs to wait for the history to be >>> imported. There's no real reason it needs to be a big deal either, we >>> could test out another project site and keep it the way it currently is >>> still with not much extra effort, just someone/somescript needs to push >>> to the new project page after committing to SVN. Basically all it would >>> take beyond that is for one of the founders/core members to take some >>> time to setup an account and push the code. >> >> Before moving all main commiters should agree (e.g. Nick and Enrico), > > Enrico doesn't care, you like it, so the one who will have to decide > is Nick :-). Yep ^^ >> but I think the creating par would not be the real problem. As discussed >> further later in thread the problem is more setting up correct hooks to >> keep all repos up to date. > > But those hooks were meant to be used to have a git mirror on GitHub > if there's no VCS switch (mirroring the current git mirror of SVN). I > don't see any point in having multiple git mirrors if you switch to > git (well, actually everybody's personal clone would be such a > mirror). I think we shouldn't drop e.g. the git.geany.org mirror if we can keep it, so we'd need a hook in the official repo to push to it or whatever. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SplitWindow Windows support/fixes (was: Re: Geany-Newsletter issues #2 reaching target line)
On Mon, 09 May 2011 15:35:00 +0200, Frank wrote: >Am 09.05.2011 15:27, schrieb Colomban Wendling: >> Le 08/05/2011 23:18, Matthew Brush a écrit : >>> On 05/08/11 10:08, Colomban Wendling wrote: >>> just need to re-apply the commits: http://git.geany.org/geany/commit/?id=757654e14b40d85c95c50ab422e3bcd63fa7fd29 http://git.geany.org/geany/commit/?id=1788dfa8dc6ba106a16069cf4ca79d3ee2a5533f >>> >>> Yep, that should do it. >> >> Applied again. I tested under Linux, and it works OK, no more >> selection problems, nor weird cursors. I haven't tested on Windows, >> but I guess that nothing changed on this side since Enrico tried it >> last time? Though if somebody have the time/courage/will to test it >> on Windows again, it'd be great :) > >Will give it a try once a Windowsbuild with this change is available. http://nightly.geany.org/win32/ Have fun. (I manually started the nightly build to get this new version into the Windows build. I almost finished reworking the nightlies system and will announce it once it's all running again.) Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpY9HDbRwoHY.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SplitWindow Windows support/fixes (was: Re: Geany-Newsletter issues #2 reaching target line)
On Mon, 09 May 2011 15:27:53 +0200, Colomban wrote: >Le 08/05/2011 23:18, Matthew Brush a écrit : >> On 05/08/11 10:08, Colomban Wendling wrote: >> >>> just need to re-apply the commits: >>> >>> http://git.geany.org/geany/commit/?id=757654e14b40d85c95c50ab422e3bcd63fa7fd29 >>> >>> http://git.geany.org/geany/commit/?id=1788dfa8dc6ba106a16069cf4ca79d3ee2a5533f >>> >> >> Yep, that should do it. > >Applied again. I tested under Linux, and it works OK, no more selection >problems, nor weird cursors. I haven't tested on Windows, but I guess Awesome, thank you Colomban. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpJls4ioSNXj.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
On Mon, 9 May 2011 19:44:15 +0200, Jiří wrote: >2011/5/8 Enrico Tröger : >>>Hi Enrico, >>> >>>in principle you have to put something like >>> >>>git push --mirror your_github_repository >>> >>>under .git/hooks/post-receive (in the local geany repository). When >>>creating the github repository, you should create a new >>>public/private key pair and make sure that the keys are available >>>for the user who runs the git command. If you have multiple keys or >>>there are several users, you may use this technique: >> >> Thanks for the information. >> However, this sounds like more work than I can effort to do. I just >> don't want to start with this and then it delays to ever like many >> other things I started (shame on me, but working on it :D). > >I can set up a repository at GitHub, test everything and describe what >needs to be done in greater detail. But I'll do it only if the >decision is _not_ to switch to git as a primary VCS for Geany in which >case this work wouldn't be necessary. > >> >> If anyone has time to write such a script, I'd be happy to include it >> as a hook script. >> Btw, we already have a GIT mirror at repo.or.cz: >> http://repo.or.cz/w/geany-mirror.git >> Not sure if that helps anything. > >Oh, I didn't know about it. How do you push commits there? It should >be about the same for GitHub as well. Don't push at all, repo.or.cz pulls. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpzu7ZjRcySU.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
2011/5/8 Enrico Tröger : >>Hi Enrico, >> >>in principle you have to put something like >> >>git push --mirror your_github_repository >> >>under .git/hooks/post-receive (in the local geany repository). When >>creating the github repository, you should create a new public/private >>key pair and make sure that the keys are available for the user who >>runs the git command. If you have multiple keys or there are several >>users, you may use this technique: > > Thanks for the information. > However, this sounds like more work than I can effort to do. I just > don't want to start with this and then it delays to ever like many > other things I started (shame on me, but working on it :D). I can set up a repository at GitHub, test everything and describe what needs to be done in greater detail. But I'll do it only if the decision is _not_ to switch to git as a primary VCS for Geany in which case this work wouldn't be necessary. > > If anyone has time to write such a script, I'd be happy to include it > as a hook script. > Btw, we already have a GIT mirror at repo.or.cz: > http://repo.or.cz/w/geany-mirror.git > Not sure if that helps anything. Oh, I didn't know about it. How do you push commits there? It should be about the same for GitHub as well. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
On Mon, May 9, 2011 at 16:16, Colomban Wendling wrote: >> Cons from the previous thread: >> - It's more social > > I have some cons against social networks, but there are pros here, so... > >> - Not plain enough (I guess too Web 2.0/feature-full/cluttered) > > I don't personally mind if it's not intrusive. > >> - Effort required to move the project > > That's the big part! Not that bad if you move the repository only to GitHub - see below. >> - No need to maintain changelog and authors files > > That's not true. Our ChangeLog don't contain each and every commit, nor > necessarily the whole commit message. > > Although I don't personally second such ChangeLog (mostly because we > have to maintain it and it's the biggest source of conflicts), I > understand the point of Nick and Enrico to keep it, and won't start > discussion on this again. Could you point me to the discussion? I've missed that one. (I too find a manual-maintained ChangeLog to be too much effort with too little gain.) >> Obviously I'm not suggesting that the SourceForge project page is >> deleted, just switching the main development activity to elsewhere. We >> could have a git/svn mirror over at SourceForge still, and even keep >> their bug/feature tracker, though I can't see why, since it's pretty lousy. > > The difficult part is moving bug tracking I guess. If we end up having 2 > bug trackers it'd become quite a pain :/ I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process. > >> It really wouldn't be hard either, the whole "switch" be done in >> probably 10-15 minutes, maybe 1-2hrs to wait for the history to be >> imported. There's no real reason it needs to be a big deal either, we >> could test out another project site and keep it the way it currently is >> still with not much extra effort, just someone/somescript needs to push >> to the new project page after committing to SVN. Basically all it would >> take beyond that is for one of the founders/core members to take some >> time to setup an account and push the code. > > Before moving all main commiters should agree (e.g. Nick and Enrico), Enrico doesn't care, you like it, so the one who will have to decide is Nick :-). > but I think the creating par would not be the real problem. As discussed > further later in thread the problem is more setting up correct hooks to > keep all repos up to date. But those hooks were meant to be used to have a git mirror on GitHub if there's no VCS switch (mirroring the current git mirror of SVN). I don't see any point in having multiple git mirrors if you switch to git (well, actually everybody's personal clone would be such a mirror). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
On 5/9/2011 9:27 AM, Colomban Wendling wrote: I second the Git switch, so 1/4 (and I guess Frank will second too). Just note I have no experience using GitHub (or even no real with Gitorious) or working with pull requests and co, but I'd be happy to git it a try -- and probably adopt it. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel I would also like to see a switch to using git, not that my opinion is worth *that* much :-) ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] hex mode
I am using Scite every day at work to open files containing NULL characters (that Geany can't open). Scite is based on Scintilla, and it doesn't stop at the first NULL character. I guess it should be possible to open binary files in Geany too ... 2011/4/19 Matthew Brush > On 04/19/11 02:30, Lex Trotman wrote: > >> [...] >> >>> I thought about writing such a plugin before, but not using Scintilla >>> directly, I think I even might've wrote a little code for it. I was >>> looking >>> at using GtkHex[1] and messing with the main documents tab like the >>> Devhelp >>> plugin does. Getting a hex viewing widget into Geany is pretty easy, but >>> hooking it in to handle different filetypes and whatnot would probably be >>> a >>> little harder. >>> >> >> Not sure what you mean by handle filetypes, I thought the point of >> something like this would be to handle it as hex, no matter what the >> file was? >> > > My idea was for viewing/editing binary files only, but it could be any file > really. But mostly I was referring to things like tying in with the > document open signal, figuring out if it's a binary file, hijacking the > "document open" so it's displayed in GHex/GtkHex, preventing Geany from > trying to display it in Scintilla, integration with all the other features > like fonts, zooming, printing, etc. That was the point when I decided to > just use an external hex viewer for binary files :) > > Cheers, > Matthew Brush > > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
Le 03/05/2011 00:43, Jiří Techet a écrit : > On Mon, May 2, 2011 at 16:33, Thomas Martitz > wrote: >> Am 02.05.2011 00:18, schrieb Jiří Techet: >>> >>> Yes, I would also prefer if there was a proper and complete git switch >>> (it would greatly save maintainer's work IMO) but I haven't seen much >>> enthusiasm from the core developers for the move so it's better if >>> people who use git have at least an up-to-date git mirror from which >>> they can create their private branches. >>> >> >> The core developers don't show very much enthusiasm since a while *in >> general*. Well, that's not entirely true I admit, Colomban is doing a great >> job and Nick has been more active recently too. But my general feeling, that >> the community around is more active these days, remains. > > But the question of whether to switch to git or not has to be decided > by the very core developers (Enrico, Nick). Without their decision all > our discussion is pointless because the switch just won't happen. > > So direct question: Enrico, Nick, what's your opinion on the git > switch? As Matthew said, it seems that it's possible to access a > github repository both via svn and git so both the current workflow > and git-based workflow should be possible. Of course I'll try to help > with whatever I can during the migration. I second the Git switch, so 1/4 (and I guess Frank will second too). Just note I have no experience using GitHub (or even no real with Gitorious) or working with pull requests and co, but I'd be happy to git it a try -- and probably adopt it. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
Le 28/04/2011 23:43, Jiří Techet a écrit : > On Thu, Apr 28, 2011 at 07:01, Matthew Brush wrote: >> On 04/27/11 21:01, Lex Trotman wrote: - No need to maintain changelog and authors files >>> >>> Changelog and authors are still needed for tarballs, but maybe they >>> can be automated? >> >> Seems not too hard with git log and some shell script[1]. I think the >> original thread also mentions a way (or that it's possible). > > http://live.gnome.org/Git/ChangeLog As said in another message, our ChangeLog isn't a simple "git log" mirror. See the other mail for a few more details. >> There would be no need to use "Thanks" in each commit message, since the >> author of the commit is the person who wrote the code in it, for example[2] >> where I just sent Neil a properly formatted patch of my local commit and he >> applied it directly, keeping the history in tact. If it needed fixing to >> get added into the main code, this will also be reflected in the history by >> the next commits to fix it (and I believe the original thread says another >> way to do this), so no need for "Based on patch by ..." in any commit >> messages either. > > Just for completeness, sometimes the patch needs to be modified by the > maintainer but in these cases it's better to have 2 commits - one > containing the original patch and one with the maintainer's changes > (especially when the modification actually screws up the original > patch). I don't like the idea of committing something I don't second, e.g. I patch I have to modify just after. For me the primary goal of a commit is to reflect a particular change, and being able to revert it/cherry-pick it, etc., so it should be a whole, no less and no more. If I have to commit someone's patch with changes, I would tend to either leave it to him if the modifications are minimal (e.g. a few formatting issues, a missing free(), etc.) or take it to me, adding original author's mention (if the modifications are important). Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
Hey, Sorry for the response delay, but not I answer: Le 28/04/2011 03:36, Matthew Brush a écrit : > Summary from previous thread: > The people in the thread who do not want to switch to Git, or those who > don't seem to care either way, are those who have commit access to > Subversion on SourceForge. Most (if not all) contributors to Geany are > using Git (via git-svn). The workflow for those who don't have commit > access on the subversion repository, when contributing to Geany is > sub-optimal (to put it politely). SourceForge is painfully slow and the > interface for viewing SVN source code online isn't great. Agreed, mostly on the fact that SF is quite weirdly painful to use in many situations. > I think the reason GitHub/Gitorious is mentioned so much is not only > because of the "Git" in their name, but also because it allows people > who don't have commit access to actually be active members in the > community, by means of having their public forked repositories, sending > merge/pull requests, etc. I don't know GitHub, but it looks great at first glance. The only thing I don't necessarily like is being this much depend of an external host, but it's probably the cost of not maintaining our own whole set of services and servers. And anyway we already have this with SF. The only thing I think would be awesome and really useful would be to have the GitHub wiki on geany.org (or vice-versa). Since its seems to be an open-source Wiki software using Git, it may be doable; and that'd be awesome. > Cons from the previous thread: > - It's more social I have some cons against social networks, but there are pros here, so... > - Not plain enough (I guess too Web 2.0/feature-full/cluttered) I don't personally mind if it's not intrusive. > - Effort required to move the project That's the big part! > - Having to learn a new VCS for those not familiar with Git True. Though I think Git is quite handy for the basic features (commit/diff/log/pull/push/merges/branches/cherry-picks), probably less with more advanced ones, but they are less used, aren't they? (though I rebase almost everyday, but still :D) > Pros from the thread: > [...] > - Moving the codebase and history is very easy, for example using the > script from the thread or GitHub offers you to import a SVN repository > through the web interface when creating a new repository. That's a great point for GitHub > - Easier to contribute to the project for those without write access > - Faster hosting and better interface. Seems like I agree. > - Harder to have patches slip through the crack. > - Not having to maintain/create patches as much/at all. That's not necessarily true, but yes, patches at least have a proper managing system. > - No need to maintain changelog and authors files That's not true. Our ChangeLog don't contain each and every commit, nor necessarily the whole commit message. Although I don't personally second such ChangeLog (mostly because we have to maintain it and it's the biggest source of conflicts), I understand the point of Nick and Enrico to keep it, and won't start discussion on this again. > - Proper attribution, blame and history for contributors and not having > to put "Thanks" in all the commit messages. That's a good point, too. > Not sure if I missed any, or misconstrued them. > > Here's some features of better project hosting sites. I'm listing > things from GitHub because I know it better than Gitorious and others: > > - Great source code viewer, branch/file browser, history/commit viewer. > - Ability to link to and comment on commits and even specific lines of a > commit, for code review, etc. > - Nice network graph viewer to get a better idea of what everyone else > is working on, needs to be commited, etc[2]. > - Tracker for pull/merge requests so no need for contributors to > generate/maintain patch(sets) and keep bumping ML threads so their > patches don't go forgotten. > - Fork queue to compare other peoples repositories' commits against your > repository to cherry pick specific commits, with an indication of > whether or not the commit/patch will likely cleanly apply > - Good issue/bug tracker > - Built-in Wiki software > - Nice graphs to show languages, impact, commit activity, etc > - Web hooks to notify by email/ML, IRC and other services of commits, > etc.[4] > - No need to create nightly tarballs separately since the server takes > care of this automatically when users clicks the Download link. Yeah, GitHub functionality looks great. I don't think Gitorious offers as much functionality (e.g. no bug tracker). The one I probably misses the most on SF is automated ticked closing from a commit (e.g. the "closes #foo" stuff). > Hopefully this will stir up a little discussion about actually switching > because every time I use SourceForge I die a little inside :) I think > switching to one of the Git project hosting sites will really help the > community/contributors get involved and feel l
Re: [Geany-devel] Geany-Newsletter issues #2 reaching target line
Am 09.05.2011 15:34, schrieb Colomban Wendling: > Le 05/05/2011 16:45, Matthew Brush a écrit : >> On 05/05/11 02:11, Frank Lanitz wrote: >> >>> My understanding was that this has been fixed and now is working also on >>> Windows. What is pending here? >> >> I don't think it ever got fixed/applied. Last I remember, Enrico said >> he will do in the next few days, and then I never heard anything more. >> What's pending is the patch to fix the original Windows bug[1][2] and >> re-enabling the Split Window plugin for Windows build[3][4]. > > Now done. Sorry for the long delay, and thanks again for the hard work! Cool, so we don't need to change the newsletter at this point ;) Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SplitWindow Windows support/fixes (was: Re: Geany-Newsletter issues #2 reaching target line)
Am 09.05.2011 15:27, schrieb Colomban Wendling: > Le 08/05/2011 23:18, Matthew Brush a écrit : >> On 05/08/11 10:08, Colomban Wendling wrote: >> >>> just need to re-apply the commits: >>> >>> http://git.geany.org/geany/commit/?id=757654e14b40d85c95c50ab422e3bcd63fa7fd29 >>> >>> http://git.geany.org/geany/commit/?id=1788dfa8dc6ba106a16069cf4ca79d3ee2a5533f >>> >> >> Yep, that should do it. > > Applied again. I tested under Linux, and it works OK, no more selection > problems, nor weird cursors. I haven't tested on Windows, but I guess > that nothing changed on this side since Enrico tried it last time? > Though if somebody have the time/courage/will to test it on Windows > again, it'd be great :) Will give it a try once a Windowsbuild with this change is available. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Newsletter issues #2 reaching target line
Le 05/05/2011 16:45, Matthew Brush a écrit : > On 05/05/11 02:11, Frank Lanitz wrote: > >> My understanding was that this has been fixed and now is working also on >> Windows. What is pending here? > > I don't think it ever got fixed/applied. Last I remember, Enrico said > he will do in the next few days, and then I never heard anything more. > What's pending is the patch to fix the original Windows bug[1][2] and > re-enabling the Split Window plugin for Windows build[3][4]. Now done. Sorry for the long delay, and thanks again for the hard work! Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SplitWindow Windows support/fixes (was: Re: Geany-Newsletter issues #2 reaching target line)
Le 08/05/2011 23:18, Matthew Brush a écrit : > On 05/08/11 10:08, Colomban Wendling wrote: > >> just need to re-apply the commits: >> >> http://git.geany.org/geany/commit/?id=757654e14b40d85c95c50ab422e3bcd63fa7fd29 >> >> http://git.geany.org/geany/commit/?id=1788dfa8dc6ba106a16069cf4ca79d3ee2a5533f >> > > Yep, that should do it. Applied again. I tested under Linux, and it works OK, no more selection problems, nor weird cursors. I haven't tested on Windows, but I guess that nothing changed on this side since Enrico tried it last time? Though if somebody have the time/courage/will to test it on Windows again, it'd be great :) Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
Le 08/05/2011 17:50, Enrico Tröger a écrit : > On Thu, 05 May 2011 00:40:43 +0200, Colomban wrote: > >>> Also, it would make it easier to migrate to using Glade 3 with >>> GtkBuilder instead of Glade 2 >> >> Well, not completely sure about this, even though I like GtkBuilder and >> Glade3 (it's s nicer than Glade2 :p): GtkBuilder was *introduced* >> in 2.12, which means the code is quite young with this release, maybe >> having important issues. I don't mean we shouldn't try to use it, but >> simply that it may be a problem because some important fixes might have >> happened in a newer release. > > Good point. > But there is probably one way to find it out: test it :). > Seriously, I think we could try to get a rough converted version and > then test it on GTK 2.12.0 (or .x) to check how it works. But not today > and tomorrow. Yeah of course, I'm not saying we shouldn't try it, but simply that we should do it with some care. If it appears it works seamlessly, I'd be really happy :) Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
Le 08/05/2011 17:47, Enrico Tröger a écrit : > On Wed, 4 May 2011 23:40:17 +0200, Jiří wrote: > > [...] > >> Porting to GTK 3 is pretty straightforward but it really depends how >> many GTK2-specific things Geany uses. I can have a look at it once a >> GTK3-compatible Scintilla is used by Geany. > > I'm most afraid of GSEAL. Probably we'll need to have a bunch of > wrapper functions because not all of the suggested accessor functions > are available on older GTK versions. But this is probably just a little > work to write these wrappers, nothing difficult to solve (I hope :D). Yeah, sealed members might be the most important work from our side, but faking accessors is quite easy (though boring to do). Basically, something like #if ! GTK_CHECK_VERSION(the-version, that-introduced, the-accessor) #define gtk_some_accessor(w) ((w)->member) #endif The difficulties comes from: 1) finding the actual GTK version that introduced the accessor 2) the amount of accessors to fake But before worrying, maybe trying to build with -DGSEAL_ENABLE is the right thing to do ^^ Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
