Hi,
Somewhere in the discussion of the last week Lex Trotman wrote:
The Scintilla editing component (everything in the Scintilla directory) is an independent project at http://www.scintilla.org. Geany tries to only use unmodified versions from that project. Could you please send your changes to Scintilla and they will flow through to Geany.
I probably should let you know that Scintilla has just undergone a significant and partly incompatible change in lexer structure, so your patches may need to be adjusted for the Lexer of the new Scintilla.
Anyone have any idea when the scintilla component is going to be updated?
Cheers, Erik
Erik de Castro Lopo wrote:
Anyone have any idea when the scintilla component is going to be updated?
I notice the documentation here:
http://www.geany.org/manual/hacking.html#syntax-highlighting
says:
We won't accept adding a lexer that conflicts with one in Scintilla. All new lexers should be submitted back to the Scintilla project to save duplication of work.
I agree with the idea of trying to avoid duplication of work. I would like to add syntax highlighting for LLVM but with Geany being out of sync with Scintilla I'm not sure where I should be working. If I do it in Geany then its lost when Geany updates its version of Scintilla and if I do it in Scintilla I have no easy way of testing it.
On top of that myself and others are submitting patches to this mailing list and not even having them acknowledged by anyone with SVN commit access.
I know this is an open source project run by volunteers who may not always have time free to work on the project (I am the author of two well known and widley used FOSS libraries). However, it would be nice if the Geany developers could do one or more of the following:
a) Say "I'm $too_busy_to_work_on_geany now. I will attend to this on $date."
b) Sort out the Scintilla issue as soon as possible and document how the Scintilla files are brought into Geany.
c) Give SVN access to people they trust who can review and apply patches sent to this list.
d) Start a development branch where people can submit patches and have them applied in a timely manner so other people can try them out and comment on them.
Erik
Am Dienstag, den 10.08.2010, 09:02 +1000 schrieb Erik de Castro Lopo:
On top of that myself and others are submitting patches to this mailing list and not even having them acknowledged by anyone with SVN commit access.
That's just because hard and long work within the week. At least for me, and I guess it's the same for the other guys.
You can be sure your patches have been or will be seen, reviewed and most likely also applied. It may just take a bit at present, but I'll promise to better myself.
Regards, Dominic
Dominic,
Thanks for your response.
Dominic Hopf wrote:
That's just because hard and long work within the week. At least for me, and I guess it's the same for the other guys.
I know how it can be, but it does sound like you need to increase the head count of the inner circle so the possibility of someone being able to look at patches increases.
Cheers, Erik
On 10 August 2010 09:34, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Dominic,
Thanks for your response.
Dominic Hopf wrote:
That's just because hard and long work within the week. At least for me, and I guess it's the same for the other guys.
I know how it can be, but it does sound like you need to increase the head count of the inner circle so the possibility of someone being able to look at patches increases.
Hi Erik,
Also I think to some extent you have been unlucky and hit a time when many people happen to be otherwise busy, for instance I know that one of the primary devs just moved house. And European holiday season :-)
I am only answering mails not working on the build-system until I catch up work delays etc. I have always found that the primary devs have always been very responsive and helpful, so this period is unusual.
That said, as Geany seems to be getting more use and additions which are moving it to be suitable for bigger projects, perhaps a second tier of developers with extra branches for patches/changes to be tested could take some of the pressure off the primary guys.
Cheers Lex
Cheers, Erik
--
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 10 Aug 2010 09:02:30 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Erik de Castro Lopo wrote:
Anyone have any idea when the scintilla component is going to be updated?
I notice the documentation here:
http://www.geany.org/manual/hacking.html#syntax-highlighting
says:
We won't accept adding a lexer that conflicts with one in Scintilla. All new lexers should be submitted back to the Scintilla project to save duplication of work.
I agree with the idea of trying to avoid duplication of work. I would like to add syntax highlighting for LLVM but with Geany being out of sync with Scintilla I'm not sure where I should be working. If I do it in Geany then its lost when Geany updates its version of Scintilla and if I do it in Scintilla I have no easy way of testing it.
Normally it's not a problem, just work on Geany, then send a patch to Scintilla. This may still work but you may want to avoid any lexer properties ATM.
It is reasonable to delay updating a big change like the Scintilla lexer changes, particularly as they are likely to introduce bugs. We may want to make a 0.20 release without a possibly slightly broken Scintilla.
On top of that myself and others are submitting patches to this mailing list and not even having them acknowledged by anyone with SVN commit access.
I know this is an open source project run by volunteers who may not always have time free to work on the project (I am the author of two well known and widley used FOSS libraries). However, it would be nice if the Geany developers could do one or more of the following:
a) Say "I'm $too_busy_to_work_on_geany now. I will attend to this on $date."
Enrico & I have said we're busy in some list mails.
The plan is to make a 0.19.1 release, then we'll start applying patches.
b) Sort out the Scintilla issue as soon as possible and
See above.
document how the Scintilla files are brought into Geany.
Ask Enrico.
c) Give SVN access to people they trust who can review and apply patches sent to this list.
d) Start a development branch where people can submit patches and have them applied in a timely manner so other people can try them out and comment on them.
Maybe. When we have time we'll need to look at these things.
Regards, Nick
Il giorno 10/ago/2010, alle ore 14.17, Nick Treleaven ha scritto:
On Tue, 10 Aug 2010 09:02:30 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
c) Give SVN access to people they trust who can review and apply patches sent to this list.
d) Start a development branch where people can submit patches and have them applied in a timely manner so other people can try them out and comment on them.
Maybe. When we have time we'll need to look at these things.
A good idea may be switching to mercurial (as Scintilla did) in order to facilitate fork and patch queue development, being able to merge it back when they are ready.
IMHO http://bitbucket.org may be a good candidate, even better that sourceforge for repos 'cause, like on github, they allow an easy management for fork and patch queue.
Alessio -- Alessio Caiazza Agenzia Regionale di Sanità Toscana Viale Giovanni Milton 7, 50129 Firenze alessio.caiazza@ars.toscana.it | Fax. 055.3841405
On Tue, 10 Aug 2010 15:32:41 +0200 Alessio Caiazza alessio.caiazza@ars.toscana.it wrote:
A good idea may be switching to mercurial (as Scintilla did) in order to facilitate fork and patch queue development, being able to merge it back when they are ready.
IMHO http://bitbucket.org may be a good candidate, even better that sourceforge for repos 'cause, like on github, they allow an easy management for fork and patch queue.
Using a DVCS was already under discussion with a few pros for using git. Maybe you can search a bit inside archive of this list. There has been a huge number of mails around start of June.
Beside of the advantages/disadvantages mentioned there I don't see that this will be able to solve the issue, that some of the 'core'devs needs to review a patch before merging it into official trunk.
Cheers, Frank
Frank Lanitz wrote:
Using a DVCS was already under discussion with a few pros for using git. Maybe you can search a bit inside archive of this list. There has been a huge number of mails around start of June.
I don't particularly like git, but git would be a huge improvement over SVN.
Beside of the advantages/disadvantages mentioned there I don't see that this will be able to solve the issue, that some of the 'core'devs needs to review a patch before merging it into official trunk.
Assuming for the moment that git (and github) is used, the core devs will probably find it easier to pull patches from other git trees than manually applying patches from the mailing list.
Secondly, havin geany in git will make life easier for people like me and Jiří Techet who are keeping a bunch of patches on top of what is currently in SVN (I've currently got a set of 9 quilt patches I apply to whatever is in SVN head).
Erik
On Wed, 11 Aug 2010 19:22:52 +1000, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Frank Lanitz wrote:
Using a DVCS was already under discussion with a few pros for using git. Maybe you can search a bit inside archive of this list. There has been a huge number of mails around start of June.
I don't particularly like git, but git would be a huge improvement over SVN.
Beside of the advantages/disadvantages mentioned there I don't see that this will be able to solve the issue, that some of the 'core'devs needs to review a patch before merging it into official trunk.
Assuming for the moment that git (and github) is used, the core devs will probably find it easier to pull patches from other git trees than manually applying patches from the mailing list.
Applying a patch is the smallest issue here as with a wellformed patch its only something like patch -p0 < some_patch. Reviewing a patch and testing etc. cannot be solved by any VCS.
Secondly, havin geany in git will make life easier for people like me and Jiří Techet who are keeping a bunch of patches on top of what is currently in SVN (I've currently got a set of 9 quilt patches I apply to whatever is in SVN head).
From my understanding Jiří is already using git with git-svn on his
local working space. Not sure whether something like this is available for Mercurial. However, I don't want to start a new discussion about git and co at the moment as its not adding any additional value to.
Thanks, Frank
Frank Lanitz wrote:
Applying a patch is the smallest issue here as with a wellformed patch its only something like patch -p0 < some_patch. Reviewing a patch and testing etc. cannot be solved by any VCS.
No, but if Jiří generates a patch and applies it to his tree and I pull the same patch into my tree and we both run it for a week, and vouch for it the the core devs probably shouldn't need to do as much testing.
As far as I see it, thats a win for everyone.
Erik
On Wed, Aug 11, 2010 at 11:56, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Frank Lanitz wrote:
Applying a patch is the smallest issue here as with a wellformed patch its only something like patch -p0 < some_patch. Reviewing a patch and testing etc. cannot be solved by any VCS.
No, but if Jiří generates a patch and applies it to his tree and I pull the same patch into my tree and we both run it for a week, and vouch for it the the core devs probably shouldn't need to do as much testing.
You can do this already - I forgot to mention that the patches are available here:
http://gitorious.org/~techy/geany/gproject-geany
under the for_review2 branch (the latest patches are missing though). I "own" the geany project at gitorious and update it from time to time so you can make your clone of it and use as a repository for your patches. The problem is that I have to keep the repository project up to date with geany's official repository manually (and I haven't done this for some time now). I don't know how the geany's git mirror is created but isn't there some way to push the changes to gitorious automatically as well? Having an up to date mirror at gitorious (or somewhere else) where you can have your own clones with patches should satisfy most users for now.
Jiri
As far as I see it, thats a win for everyone.
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Aug 11, 2010 at 11:50, Frank Lanitz frank@frank.uvena.de wrote:
On Wed, 11 Aug 2010 19:22:52 +1000, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Frank Lanitz wrote:
Using a DVCS was already under discussion with a few pros for using git. Maybe you can search a bit inside archive of this list. There has been a huge number of mails around start of June.
I don't particularly like git, but git would be a huge improvement over SVN.
Beside of the advantages/disadvantages mentioned there I don't see that this will be able to solve the issue, that some of the 'core'devs needs to review a patch before merging it into official trunk.
Assuming for the moment that git (and github) is used, the core devs will probably find it easier to pull patches from other git trees than manually applying patches from the mailing list.
Applying a patch is the smallest issue here as with a wellformed patch its only something like patch -p0 < some_patch. Reviewing a patch and testing etc. cannot be solved by any VCS.
Secondly, havin geany in git will make life easier for people like me and Jiří Techet who are keeping a bunch of patches on top of what is currently in SVN (I've currently got a set of 9 quilt patches I apply to whatever is in SVN head).
From my understanding Jiří is already using git with git-svn on his local working space. Not sure whether something like this is available
I'm using the git mirror that geany provides. I keep master in sync with the geany mirror without any extra patches applied (so basically I do 'git pull' in master now and then) and have my patches in a separate branch. After pulling from geany's repository I checkout the branch with my patches and do 'git rebase master' which puts my patches on top of the current master. When sending the patches to the mailing list, I do 'git send-email --attach --compose HEAD~X..', where X is the number of patches I'm sending. I make the commit messages detailed enough so they serve as the email body too. Just mentioning this workflow as others might find it useful as well.
for Mercurial. However, I don't want to start a new discussion about git and co at the moment as its not adding any additional value to.
Agree. I think everything has already been said in the long thread some time ago. My understanding is that the outcome of the discussion was that nobody is really against switching to a distributed version control system for geany (and some people would really like to do the switch) but the core developers don't have time to do the migration and learn how to adjust their workflow with a DVCS so the switch won't happen now but may happen later in the future. I understand and respect this decision. (The only thing I would still like to have is the .gitignore file distributed with geany.)
Jiri
Thanks, Frank
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 11.08.2010 12:56, Jiří Techet wrote:
I'm using the git mirror that geany provides. I keep master in sync with the geany mirror without any extra patches applied (so basically I do 'git pull' in master now and then) and have my patches in a separate branch. After pulling from geany's repository I checkout the branch with my patches and do 'git rebase master' which puts my patches on top of the current master. When sending the patches to the mailing list, I do 'git send-email --attach --compose HEAD~X..', where X is the number of patches I'm sending. I make the commit messages detailed enough so they serve as the email body too. Just mentioning this workflow as others might find it useful as well.
I hope you don't rebase, because I'm tracking your branches and it's a pain if upstream does rebasing :(
Best regards.
Thomas Martitz wrote:
On 11.08.2010 12:56, Jiří Techet wrote:
I'm using the git mirror that geany provides. I keep master in sync with the geany mirror without any extra patches applied (so basically I do 'git pull' in master now and then) and have my patches in a separate branch. After pulling from geany's repository I checkout the branch with my patches and do 'git rebase master' which puts my patches on top of the current master. When sending the patches to the mailing list, I do 'git send-email --attach --compose HEAD~X..', where X is the number of patches I'm sending. I make the commit messages detailed enough so they serve as the email body too. Just mentioning this workflow as others might find it useful as well.
I hope you don't rebase, because I'm tracking your branches and it's a pain if upstream does rebasing :(
Thats why I'm using quilt :-).
Erik
On 11.08.2010 13:52, Thomas Martitz wrote:
I hope you don't rebase, because I'm tracking your branches and it's a pain if upstream does rebasing :(
Ah there we go, now I'm in trouble pulling from you :(
On Wed, Aug 11, 2010 at 13:52, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
On 11.08.2010 12:56, Jiří Techet wrote:
I'm using the git mirror that geany provides. I keep master in sync with the geany mirror without any extra patches applied (so basically I do 'git pull' in master now and then) and have my patches in a separate branch. After pulling from geany's repository I checkout the branch with my patches and do 'git rebase master' which puts my patches on top of the current master. When sending the patches to the mailing list, I do 'git send-email --attach --compose HEAD~X..', where X is the number of patches I'm sending. I make the commit messages detailed enough so they serve as the email body too. Just mentioning this workflow as others might find it useful as well.
I hope you don't rebase, because I'm tracking your branches and it's a pain if upstream does rebasing :(
Well, the work is done in the way so that I can send clean sequence of patches to this mailing list. If I were doing merges all the time this wouldn't be possible. Also when I find a bug in one of the patches I do a commit that I squash with the original patch - I seriously doubt that Nick wants to review one patch together with all its fixes scattered in this mailing list.
That said, I don't rebase anything in the for_review* branches - these are those I have sent here for review and people don't want to see these changing. I'll push the latest changes as for_review3 (rebased so that the original patches will be modified). But I consider the remaining branches as my private branches and do rebase them.
Regarding rebasing it's not such a problem for not extremely huge projects with too many contributors whose work is likely to interfere. If you look at the history of any gnome library like gtk and glib you'll see that most of the time the work is rebased on top of master instead of merging people's branches so the history is mostly linear. Linux kernel is the opposite example.
Jiri
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel