Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]
Quoting Enrico Weigelt weig...@metux.de: * Pavel Roskin pro...@gnu.org schrieb: Hi, What's the point? I could have given you full access to the mc repository on the same site. After all, it's just a mirror. You could have rewritten the whole repository. Now we have two competing mirrors for the same project. I'm not going to keep it this way. Hey, it's just dumb *readonly* mirror. nobody can commit there (not even me) - it just syncs itself from the master periodically. the idea behind is nothing more to have yet another publically available copy to keep some unncessary traffic from the weak mc.o server. and in case something bad happens to the server, we've got an backup. It's not a fork or anything like that. I understand that it's a mirror and not a fork. I really don't see the problem. The problem is that the mirror already existed on that site. Now we have two mirrors. It's confusing to the users. Some may be tracking my mirror now. Instead of giving you control over the existing mirror, I'll need to ask the site administration to remove my mirror. The users will have to switch to your repository. I believe it's important that the project developers act as a team and coordinate their actions. I realize I'm not a team member anymore, but I've been maintaining the mirror for along time. I spent quite a lot of time mapping CVS authors to the real names, and that mapping is used in your repository. It's just not nice to set up an alternate mirror without bothering to ask me. It's not like I'm going to spend much time on the project anyway, but such treatment will discourage me from dealing with the new team. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Trac - remove crap tickets
Hi folks, is it possible to remove certain crap tickets (I mean those which are *really* crap, like testings, accidential double-posts, etc) ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #136: ***ignore me***
#136: ***ignore me*** ---+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: metux Type: task | Status: testing Priority: trivial | Milestone: Component: adm | Version: Resolution: invalid |Keywords: Blocking: | Blockedby: ---+ Changes (by metux): * status: assigned = testing * resolution: = invalid -- Ticket URL: http://midnight-commander.org/ticket/136#comment:4 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #135: [PATCH] Drop bundled libintl (was: Drop bundled libintl)
#135: [PATCH] Drop bundled libintl --+- Reporter: metux| Owner: metux Type: enhancement | Status: accepted Priority: minor| Milestone: Component: mc-core | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: --+- Changes (by metux): * status: assigned = accepted -- Ticket URL: http://www.der-winnie.de/trac/ticket/135#comment:4 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #138: [PATCH] 4.6.1: Fixup homepage url
#138: [PATCH] 4.6.1: Fixup homepage url --+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: Type: defect| Status: new Priority: major | Milestone: Component: mc-core | Version: 4.6.1 Keywords:| Blocking: Blockedby:| --+ This patch fixes the homepage url to http://www.midnight-commander.org/ in various locations -- Ticket URL: /ticket/138 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #137: [PATCH] git: Fixup homepage url
#137: [PATCH] git: Fixup homepage url --+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: Type: defect| Status: new Priority: major | Milestone: Component: mc-core | Version: 4.6.1 Keywords:| Blocking: Blockedby:| --+ This patch fixes the homepage url to http://www.midnight-commander.org/ in various locations -- Ticket URL: /ticket/137 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #138: [PATCH] (4.6.1) Fixup homepage url (was: [PATCH] 4.6.1: Fixup homepage url)
#138: [PATCH] (4.6.1) Fixup homepage url ---+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: Type: defect | Status: new Priority: critical | Milestone: 4.6.2 Component: mc-core | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: ---+ Changes (by metux): * priority: major = critical * milestone: = 4.6.2 Old description: This patch fixes the homepage url to http://www.midnight-commander.org/ in various locations New description: This patch fixes the homepage url to http://www.midnight-commander.org/ in various locations -- -- Ticket URL: http://midnight-commander.org/ticket/138#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #137: [PATCH] (git) Fixup homepage url (was: [PATCH] git: Fixup homepage url)
#137: [PATCH] (git) Fixup homepage url ---+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: Type: defect | Status: new Priority: critical | Milestone: 4.6.2 Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: ---+ Changes (by metux): * priority: major = critical * version: 4.6.1 = * milestone: = 4.6.2 Old description: This patch fixes the homepage url to http://www.midnight-commander.org/ in various locations New description: This patch fixes the homepage url to http://www.midnight-commander.org/ in various locations -- -- Ticket URL: http://midnight-commander.org/ticket/137#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #45: savannah: Build system does not allow cross compiling
#45: savannah: Build system does not allow cross compiling -+-- Reporter: slavazanko | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: -+-- Comment(by metux): IMHO we just should rewrite the whole man2hlp program in perl. Maybe takes a bit more work in the first place, but should save a lot hassle in the future. -- Ticket URL: http://www.midnight-commander.org/ticket/45#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #139: compatibility_move_mc_files() still needed ?
#139: compatibility_move_mc_files() still needed ? -+-- Reporter: metux| Owner: Type: task | Status: new Priority: minor| Milestone: Component: mc-core | Version: 4.6.1 Keywords: |Blocking: Blockedby: | -+-- Just came around the function compatibility_move_mc_files() which seems to move old files like .mc.ini, .mc.hot, ... to .mc/. Actually I can't remember ever having those files, so it might be quite long ago and probably not needed anymore. Should we drop it ? -- Ticket URL: http://www.der-winnie.de/trac/ticket/139 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [r...@rover.dkm.cz: [repo.or.cz] midnight-commander clone completed]
* Pavel Roskin pro...@gnu.org schrieb: Hi, I really don't see the problem. The problem is that the mirror already existed on that site. Now we have two mirrors. It's confusing to the users. Some may be tracking my mirror now. Instead of giving you control over the existing mirror, I'll need to ask the site administration to remove my mirror. The users will have to switch to your repository. Why do you have to close your mirror ? I dont see any reason. Thousands of OSS projects get mirrored all around the world, even without explicit knowledge of the devs, and - as far as I know - nobody feels pissed about that. What's the problem ? I believe it's important that the project developers act as a team and coordinate their actions. What is there to coordinate on just some dumb unofficial mirror ? I realize I'm not a team member anymore, but I've been maintaining the mirror for along time. Wait, you really feel kicked-away, just because your mirror isn't the only one anyomore ? Quite strange, IMHO. I spent quite a lot of time mapping CVS authors to the real names, and that mapping is used in your repository. Right, and you did a great job. You volunteered to do an dirty, but important job, nobody else was willing to do. And I don't think anyone here won't appreciate that. So you *are* a valueable member of the team, and I don't see how some additional, uninteresting git mirror can change that fact. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: git+patch workflow [WAS: bundled intl stuff necessary]
Am Samstag 03 Januar 2009 21:53:20 schrieb Enrico Weigelt: * Slava Zanko slavaza...@gmail.com wrote: (bouncing back to the list ;-p) Hi, I not fully understand... How automate process of patch submission, in your mind? Okay, let's take an example: I'm currently working on some sub-project. Now I've did my work, everything seems okay for me and I'd like to publish it. All I now (ideally) would have to do is enter some quick command line (eg. including some description) and the rest goes automatic: my work is published, ticket opened, etc. Okay I work so: (on master branch): git checkout -b foobar [do some work] git add new files/changed files git diff master /tmp/$new-patch-to-publish.patch git reset --hard $sumoflastcommit (e.g. atm: 4c58d938cbe836c48c105eeb525a2ffc8dd519e5) git show # now everything should be clean and no changes should be there. git checkout master git branch -d foobar (or -D foobar if there are changes which are not merged into master) publish now the patch on trac via email or webinterface. Coming from the other side, it would be cool to have some command get me the changes from ticket xyz, so we don't have to download and apply the patches manually. Well... :) such a tool would be nice but doesn't exist atm. The best solution - use git branches for tracking patches, IMHO. hmm, heard of that, but never used it. How does it work ? hmm, do my changes then go to the current branch (assuming I've cloned from there) ? Yes, your changes will applyed to the main branch (named 'master'). You may create any count of commits (via git-commit), but this commits placed only in your local copy of repro. You may delete some of this commits, verge, revert commits... Okay, that's just normal working in the local repo ... but if you will run command 'git-push', all of your commits will frozen for changes. Because this commits transferred in parent repro and will see by any developer (via git-pull). git-pull will get latest changes from parent repro (like svn up, or full command: svn update). But this commits directly to our master repo, thus breaking our workflow, right ? Yes of course... Only commit the patch after it is acked... :) If you want to have own 'sandbox' with some patches (not included in 'master'), you may create new local branch: Can I freely create branches within the master repo ? And more important: *should* I do this ? Yes why not.. they are local as long as you don't push them to the server via git push $localbranch origin and this is something which should be done _very_ rare. As I think that there are several people not very familiar with git I'll write a small Howto use the git repro together with our workflow. After I'm finished I'll publish the url here. Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #135: Drop bundled libintl
#135: Drop bundled libintl --+- Reporter: metux| Owner: metux Type: enhancement | Status: assigned Priority: minor| Milestone: Component: mc-core | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: --+- Changes (by metux): * owner: = metux * status: new = assigned -- Ticket URL: http://www.der-winnie.de/trac/ticket/135#comment:1 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Trac - remove crap tickets
Am Sonntag 04 Januar 2009 09:44:43 schrieb Enrico Weigelt: Hi folks, is it possible to remove certain crap tickets (I mean those which are *really* crap, like testings, accidential double-posts, etc) ? Yes.. deleting via shell should be possible for me :) Which ticket should be removed? Greetings Winnie ps: There is also a plugin for that.. I'll consider to add it to trac. -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #135: Drop bundled libintl
#135: Drop bundled libintl -+-- Reporter: metux| Owner: Type: enhancement | Status: new Priority: minor| Milestone: Component: mc-core | Version: 4.6.1 Keywords: |Blocking: Blockedby: | -+-- Drop the bundled / builtin intl library - use system-installed one only. -- Ticket URL: http://midnight-commander.org/ticket/135 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #129: FHS-Break: cons.saver should be in ${libexecdir}/mc
#129: FHS-Break: cons.saver should be in ${libexecdir}/mc
-+--
Reporter: metux| Owner:
Type: defect | Status: new
Priority: minor| Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
-+--
cons.saver is currently located in ${libdir}/mc, which clearly breaks FHS.
Instead it should go to ${libexecdir}/mc
--
Ticket URL: http://www.der-winnie.de/trac/ticket/129
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #125: allocate and free memory via mc-wrappers
#125: allocate and free memory via mc-wrappers -+-- Reporter: slavazanko | Owner: Type: enhancement | Status: new Priority: major| Milestone: 4.6.2 Component: mc-core | Version: 4.6.1 Keywords: memory |Blocking: Blockedby: | -+-- Now in sources mixed many technologies for working with memory: - system functions (malloc/free) - glib functions (g_malloc/g_free) - self-made function (like in vfs/mcserv.c:127) This patch is a first attempt to reorganize work with memory - only replace malloc with mc_malloc; g_malloc with mc_malloc, [g_]free with mc_free, etc. All definitions of mc_malloc|free|calloc|... placed in src/glibcompat.h. This not good place, I understand. Next step - create 'src/mc-alloc.[ch]'. This must be place of definitions memory-related functions; code from src/poptalloca.h and src/regex.c (related to definition of 'alloca' ) must will moved to mc-alloc module too. As fact, this patch is a refactoring of sources. I'm don't create mc-alloc at this time, because refactoring should made by little steps. This first step is prepare stage :) Advantages: 1) We can will realize garbage collector or debugger of memory leaks; 2) We can will realize own library 'mcglib' - for embedded systems it's very good; 3) In sources used only one technology of working with memory: mc-alloc (in future). And only in mc-alloc will use much different technologies; 4) More order in mind. :) Disadvantages: 1) All existing patches will need to hand processing... in many case. Because this patch will change a lot of files and applying patches via 'patch' or 'git-apply' command may will fail P.S. patch is too big and attached as gz-archive (because limit to size of attaches). -- Ticket URL: http://midnight-commander.org/ticket/125 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #94: Some fixups for large file support (64bit sizes) on 32bit systems
#94: Some fixups for large file support (64bit sizes) on 32bit systems -+-- Reporter: slavazanko | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: -+-- Comment(by slavazanko): related with ticket:125 -- Ticket URL: http://www.der-winnie.de/trac/ticket/94#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #93: cons.saver: open the console in non-blocking mode
#93: cons.saver: open the console in non-blocking mode -+-- Reporter: slavazanko | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: -+-- Comment(by metux): ''Comment from Miguel (on the list):'' Opening the console in non-blocking mode is a bad idea, as it means that every call that is done later on the console_fd needs to check for EWOULDBLOCK. Most of the time, it would be not return that, it would only return that under unique situations which means that testing this patch would not only be non-trivial, but someone would have to audit all the code paths. Also, this is lacking a ChangeLog explaining why this is needed. But I think that this patch should not be applied, it seems like a workaround that has not been properly implemented. -- Ticket URL: http://www.midnight-commander.org/ticket/93#comment:1 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #130: FHS-Break: global config belongs into ${sysconfdir}/mc
#130: FHS-Break: global config belongs into ${sysconfdir}/mc
-+--
Reporter: metux| Owner:
Type: defect | Status: new
Priority: minor| Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
-+--
Lots of global config files (mc.ini, mc.menu*, mc.ext, ...) are currently
installed @ ${datadir}/mc, but should go to ${sysconfdir}/mc.
--
Ticket URL: http://midnight-commander.org/ticket/130
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #124: Test ticker foo
#124: Test ticker foo +--- Reporter: Enrico Weigelt weig...@metux.de | Owner: metux Type: defect | Status: testing Priority: major | Milestone: Component: mc-core| Version: 4.6.1 Resolution: invalid|Keywords: Blocking: | Blockedby: +--- Changes (by metux): * status: assigned = testing * resolution: = invalid Old description: test 123 New description: test 123 -- -- Ticket URL: http://www.midnight-commander.org/ticket/124#comment:3 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #94: Some fixups for large file support (64bit sizes) on 32bit systems
#94: Some fixups for large file support (64bit sizes) on 32bit systems -+-- Reporter: slavazanko | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: -+-- Comment(by slavazanko): Some ideas from patch we need to keep. This mean, patch need to rework. -- Ticket URL: http://midnight-commander.org/ticket/94#comment:4 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: git+patch workflow [WAS: bundled intl stuff necessary]
Am Sonntag 04 Januar 2009 17:48:56 schrieb Oswald Buddenhagen: On Sun, Jan 04, 2009 at 05:21:29PM +0100, Patrick Winnertz wrote: git diff master /tmp/$new-patch-to-publish.patch git reset --hard $sumoflastcommit (e.g. atm: 4c58d938cbe836c48c105eeb525a2ffc8dd519e5) git show # now everything should be clean and no changes should be there. git checkout master git branch -d foobar (or -D foobar if there are changes which are not merged into master) publish now the patch on trac via email or webinterface. you want to play with git rebase -i git format-patch more? Yes.. this tools are cooler than this way I described above, that's true. I picked the above because it's using only rudimental functions of git which should already be known from other vcs systems. fwiw, the suggested backporting workflow is quite a nightmare with git, as all the merging goodies work only with forwardporting. I know but having many many branches with patches inside is also a nightmare.. in order to have a overview. instead, you need to develop on master (the conventional name for the trunk), branch for stabilization of each release, do *all* bugfixing in the current stable branch and merge it back into master each time fixes have been applied. A improvement of the situation atm would be to make master the stable branch and creating one testing branch which is based on master, wouldn't it? This would be the easiest change in oder to do not completly rework everything. major new features have to be developed on branches of master, so they can be merged back into master. everything else results in use of cherry-pick, cherry-pick was the tool I wanted to use. Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #128: FHS-Break: mc-wrapper.sh + friends belong to ${libexecdir}/mc
#128: FHS-Break: mc-wrapper.sh + friends belong to ${libexecdir}/mc
-+--
Reporter: metux| Owner:
Type: defect | Status: new
Priority: minor| Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
-+--
mc-wrapper.sh + friends are currently installed in ${datadir}/mc, which is
obviously wrong.
Should go to ${libexecdir}/mc
--
Ticket URL: http://www.der-winnie.de/trac/ticket/128
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #124: Test ticker foo
#124: Test ticker foo +--- Reporter: Enrico Weigelt weig...@metux.de | Owner: metux Type: defect | Status: assigned Priority: major | Milestone: Component: mc-core| Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: +--- Changes (by metux): * owner: = metux * status: new = assigned Old description: test 123 New description: test 123 -- -- Ticket URL: http://midnight-commander.org/ticket/124#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #136: ***ignore me*** (was: [Midnight Commander] #135)
#136: ***ignore me*** ---+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: metux Type: task | Status: assigned Priority: trivial | Milestone: Component: adm | Version: Resolution: |Keywords: Blocking: | Blockedby: ---+ Changes (by metux): * status: new = assigned * component: mc-core = adm * priority: major = trivial * version: 4.6.1 = * owner: = metux * type: defect = task Old description: Drops copy-in and build of bundled libintl New description: bad ticket -- -- Ticket URL: http://www.der-winnie.de/trac/ticket/136#comment:3 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: git+patch workflow [WAS: bundled intl stuff necessary]
On Sun, Jan 04, 2009 at 06:10:06PM +0100, Patrick Winnertz wrote: Am Sonntag 04 Januar 2009 17:48:56 schrieb Oswald Buddenhagen: fwiw, the suggested backporting workflow is quite a nightmare with git, as all the merging goodies work only with forwardporting. I know but having many many branches with patches inside is also a nightmare.. in order to have a overview. to alleviate that one could have a collector branch to which all halfways ready feature branches (and master) are merged. but from that branch no-one would ever merge; it would be a constant dead end. unless it was decided that all branches are ready at the same time, in which case it *could* be merged. instead, you need to develop on master (the conventional name for the trunk), branch for stabilization of each release, do *all* bugfixing in the current stable branch and merge it back into master each time fixes have been applied. A improvement of the situation atm would be to make master the stable branch and creating one testing branch which is based on master, wouldn't it? you can have just one testing branch from which you constantly merge fixes to master and to which you merge master each time you want all new features for a new stabilization phase. but note the *all*. merging in git is always a wholesale thing (well, in fact, you can stop the merge before the current head of a branch, but you cannot omit changes in between). major new features have to be developed on branches of master, so they can be merged back into master. everything else results in use of cherry-pick, cherry-pick was the tool I wanted to use. that way you give up almost all of the power of git, including showing cool merge history graphs. you could have the same by creating local svn repositories for disconnected development and doing the merging via patches to a conventional central repository. git just doesn't work well for the freebsd model. it is optimized for the linux model, and of that only the main line (the stable series are a little cherry-pick sucker) - for obvious reasons. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #136: [Midnight Commander] #135
#136: [Midnight Commander] #135 ---+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mc-core | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: ---+ Old description: Drops copy-in and build of bundled libintl New description: Drops copy-in and build of bundled libintl -- Comment(by metux): f***k ... should have been added to ticket #135 ;-o -- Ticket URL: http://www.midnight-commander.org/ticket/136#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #132: Feature-Request: ignore dot-files on search
#132: Feature-Request: ignore dot-files on search -+-- Reporter: metux| Owner: Type: enhancement | Status: new Priority: minor| Milestone: Component: mc-core | Version: 4.6.1 Keywords: |Blocking: Blockedby: | -+-- It would be great if the search tool would have an option to hidden files. -- Ticket URL: http://midnight-commander.org/ticket/132 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #131: FHS-Break: global config belongs into ${sysconfdir}/mc
#131: FHS-Break: global config belongs into ${sysconfdir}/mc
--+-
Reporter: metux| Owner: metux
Type: defect | Status: assigned
Priority: minor| Milestone:
Component: mc-core | Version: 4.6.1
Resolution: |Keywords:
Blocking: | Blockedby:
--+-
Changes (by metux):
* owner: = metux
* status: new = assigned
--
Ticket URL: http://www.der-winnie.de/trac/ticket/131#comment:1
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Reporting Bugs via mail works now (with drawbacks)
Hey, Yes, 'database is locking'... :( ACK. Got the same error all the time. Any idea what's up w/ the server ? Yes.. according to the ticket system for trac itself this is an error of trac 0.11 ... some issue with the sql backend. I'm searching atm for a fix (patch for trac). The issues with the load of the server should be fixed...I hope that I'll get this issue also fixed. Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #133: [PATCH] fix use of obsolete autoconf macros
#133: [PATCH] fix use of obsolete autoconf macros --+- Reporter: metux| Owner: Type: defect | Status: new Priority: minor| Milestone: 4.6.2 Component: mc-core | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: --+- Comment(by slavazanko): This patch for 4.6.1 For 'master' branch patch is a different. -- Ticket URL: http://www.der-winnie.de/trac/ticket/133#comment:1 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #65: savannah: Pascal syntax highlighting update
#65: savannah: Pascal syntax highlighting update --+- Reporter: slavazanko | Owner: winnie Type: enhancement | Status: accepted Priority: minor| Milestone: 4.6.2 Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: --+- Comment(by slavazanko): Only accepter or ticket-starter (if developer) may apply patch. For now ticket accepted to 'winnie', but you may accept yourself (and write reason). This patch will applyed only after 2 votes of developers (now only 1 vote - by Winnie, vote of pather (my) don't accepted). If any other developer will vote to this patch too (additional_pascal_keywords-rev2.patch) - patch will apply to a 'master' branch; state of ticket will change to 'testing stage'. After applying patch will need write comment to this ticket with a link to revision contains this patch. I think, this must be rules for all tickets. -- Ticket URL: http://www.midnight-commander.org/ticket/65#comment:5 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #131: FHS-Break: global config belongs into ${sysconfdir}/mc
#131: FHS-Break: global config belongs into ${sysconfdir}/mc
-+--
Reporter: metux| Owner:
Type: defect | Status: new
Priority: minor| Milestone:
Component: mc-core | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
-+--
Lots of global config files (mc.ini, mc.menu*, mc.ext, ...) are currently
installed @ ${datadir}/mc, but should go to ${sysconfdir}/mc.
--
Ticket URL: http://www.midnight-commander.org/ticket/131
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #131: FHS-Break: global config belongs into ${sysconfdir}/mc
#131: FHS-Break: global config belongs into ${sysconfdir}/mc
+---
Reporter: metux | Owner: metux
Type: defect | Status: testing
Priority: minor | Milestone:
Component: mc-core| Version: 4.6.1
Resolution: duplicate |Keywords:
Blocking: | Blockedby:
+---
Description changed by metux:
Old description:
Lots of global config files (mc.ini, mc.menu*, mc.ext, ...) are currently
installed @ ${datadir}/mc, but should go to ${sysconfdir}/mc.
New description:
Duplicate of #130 ... how can I close it ? ;-o
--
--
Ticket URL: http://www.midnight-commander.org/ticket/131#comment:3
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #126: Merge ./lib/ChangeLog with ./ChangeLog
#126: Merge ./lib/ChangeLog with ./ChangeLog -+-- Reporter: metux| Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: mc-core | Version: 4.6.1 Keywords: |Blocking: Blockedby: | -+-- The separate ChangeLog file in ./lib/ should be merged into the global one. -- Ticket URL: http://www.der-winnie.de/trac/ticket/126 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #127: FHS-Break: extfs scripts belong into ${libexecdir}/mc/extfs
#127: FHS-Break: extfs scripts belong into ${libexecdir}/mc/extfs
+---
Reporter: metux | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: vfs | Version: 4.6.1
Keywords: |Blocking:
Blockedby: |
+---
The extfs script are currently installed @ ${datadir}/mc/extfs, which is
obviously wrong.
Should go to ${libexecdir}/mc/extfs/
--
Ticket URL: http://www.der-winnie.de/trac/ticket/127
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #125: allocate and free memory via mc-wrappers
#125: allocate and free memory via mc-wrappers --+- Reporter: slavazanko | Owner: Type: enhancement | Status: new Priority: major| Milestone: 4.6.2 Component: mc-core | Version: 4.6.1 Resolution: |Keywords: memory Blocking: | Blockedby: --+- Comment(by slavazanko): related with ticket:94 -- Ticket URL: http://www.midnight-commander.org/ticket/125#comment:1 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #137: [PATCH] (git) Fixup homepage url
#137: [PATCH] (git) Fixup homepage url ---+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: Type: task | Status: new Priority: critical | Milestone: 4.6.2 Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: ---+ Changes (by slavazanko): * type: defect = task Comment: I agree with idea in patch. Homepage need to change in any case. +1. -- Ticket URL: http://www.midnight-commander.org/ticket/137#comment:3 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #136: [Midnight Commander] #135
#136: [Midnight Commander] #135 --+ Reporter: enrico.weig...@zaphod.local, metux IT service weig...@metux.de | Owner: Type: defect| Status: new Priority: major | Milestone: Component: mc-core | Version: 4.6.1 Keywords:| Blocking: Blockedby:| --+ Drops copy-in and build of bundled libintl -- Ticket URL: /ticket/136 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #65: savannah: Pascal syntax highlighting update
#65: savannah: Pascal syntax highlighting update --+- Reporter: slavazanko | Owner: winnie Type: enhancement | Status: accepted Priority: minor| Milestone: 4.6.2 Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: --+- Comment(by metux): If it's committed, should this ticket be closed ? -- Ticket URL: http://www.midnight-commander.org/ticket/65#comment:4 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #135: Drop bundled libintl
#135: Drop bundled libintl --+- Reporter: metux| Owner: metux Type: enhancement | Status: assigned Priority: minor| Milestone: Component: mc-core | Version: 4.6.1 Resolution: |Keywords: Blocking: | Blockedby: --+- Comment(by ): Drops copy-in and build of bundled libintl -- Ticket URL: /ticket/135#comment: Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #134: [PATCH] some time formatting fixes
#134: [PATCH] some time formatting fixes ---+ Reporter: Enrico Weigelt weig...@metux.de | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mc-core| Version: 4.6.1 Keywords: |Blocking: Blockedby: | ---+ this patch goes a bit deeper into the strftime()+localtime() issue. a) introduce some new shortcut macros and use them in some places b) adds additional checks (where the macros dont fit) -- Ticket URL: /ticket/134 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #94: Some fixups for large file support (64bit sizes) on 32bit systems
#94: Some fixups for large file support (64bit sizes) on 32bit systems -+-- Reporter: slavazanko | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mc-core | Version: Resolution: |Keywords: Blocking: | Blockedby: -+-- Comment(by Enrico Weigelt): * Ticket System tick...@midnight-commander.org schrieb: snip ./intl/* is completely generated by autopoint, so any local changes are useless here ... just kick off that part. Doesnt belong to this issue - kickoff ;-p cu -- Ticket URL: /ticket/94#comment: Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #133: [PATCH] fix use of obsolete autoconf macros
#133: [PATCH] fix use of obsolete autoconf macros -+-- Reporter: metux| Owner: Type: defect | Status: new Priority: minor| Milestone: 4.6.2 Component: mc-core | Version: 4.6.1 Keywords: |Blocking: Blockedby: | -+-- This patch fixes the use of obsolete autoconf macros: AC_AIX, AC_MINIX -- Ticket URL: http://www.midnight-commander.org/ticket/133 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #131: FHS-Break: global config belongs into ${sysconfdir}/mc
#131: FHS-Break: global config belongs into ${sysconfdir}/mc
+---
Reporter: metux | Owner: metux
Type: defect | Status: testing
Priority: minor | Milestone:
Component: mc-core| Version: 4.6.1
Resolution: duplicate |Keywords:
Blocking: | Blockedby:
+---
Changes (by metux):
* status: assigned = testing
* resolution: = duplicate
--
Ticket URL: http://www.midnight-commander.org/ticket/131#comment:2
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
RFC: updated workflow [WAS: Re: git+patch workflow]
Hey because of Oswald Buddenhagen's post I rethinked the workflow and discussed a better workflow with slavaz. Please comment: - every patch has to be acked twice -- if patch is broken a rev2 has to be created and be discussed - a acked patch has to be applied in a branch of master and needs to be tested there by different people. (Everybody who has tested it should report to the ticket) - after some testing in the branch we merge into the master branch (and the ticket is closed) This is pretty much the old stuff above (now we create a branch for every ticket (proposed branchname 1234_something_describing). When we want to do a release: Simply do a tag on mc-4.6.2~rc1 -- Test it and if it is okay tag also mc-4.6.2 -- Otherwise mc-4.6.2~rc2 -- Test it and if it is okay tag here mc-4.6.2 -- ... In the meantime new patches can be discussed and tested as written above.. After the release we rebase the branches and merge them into master. Please comment. Greetings Winnie ps: If this is okay I'll delete the stable branch and update/write a bit about this workflow to our wiki) -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Winnertz wrote: Some my additions for discuss... Please comment: - There should be a separate branch for each patch. The branch with the patch should be created by developer (who accept patch or by ticketstarter); - every patch has to be acked twice -- if patch is broken a *-rev2.patch (rev3, revN) has to be created (from branch) and be discussed -- Subsequent patches must be created relative from point of fork branch - a acked patch has to be merged in a branch of master and needs to be tested there by different people. (Everybody who has tested it should report to the ticket) - after some testing the branch with patch will deleted (and the ticket is closed) - if testing fail, create new branch with patch... hm, need to discuss this situation. This is pretty much the old stuff above (now we create a branch for every ticket (proposed branchname 1234_something_describing). 'one branch mean one patch(set)' it's good idea, imho. In my local git-repro this already so is. BTW, may be a situation in which no one askes for the patch (no time or busy, lazy, don't want to take responsibility for the consequences of a patch, etc). What do in this case? And what do if no testing reports? Is ticket leave in 'always testing' stage? When we want to do a release: Simply do a tag on mc-4.6.2~rc1 -- Test it and if it is okay tag also mc-4.6.2 -- Otherwise mc-4.6.2~rc2 -- Test it and if it is okay tag here mc-4.6.2 -- ... In the meantime new patches can be discussed and tested as written above.. After the release we rebase the branches and merge them into master. Good. Like a kernel-develop schema. Like for me. ps: If this is okay I'll delete the stable branch and update/write a bit about this workflow to our wiki) +1 WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklhJlkACgkQb3oGR6aVLppC3gCdGdMTREyrGenDs38MD8VEmjN5 5WoAnA6B4mpIoY31mOpmXBxQ4lusM5Zn =Skqn -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Reporting Bugs via mail works now (with drawbacks)
* Patrick Winnertz win...@debian.org schrieb: Yes.. according to the ticket system for trac itself this is an error of trac 0.11 ... some issue with the sql backend. Just a guess: sqlite locking issue ? The issues with the load of the server should be fixed...I hope that I'll get this issue also fixed. great :) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Reporting Bugs via mail works now (with drawbacks)
Am Sonntag 04 Januar 2009 22:26:18 schrieb Enrico Weigelt: * Patrick Winnertz win...@debian.org schrieb: Yes.. according to the ticket system for trac itself this is an error of trac 0.11 ... some issue with the sql backend. Just a guess: sqlite locking issue ? Jepp exactly. As trac is based on sqlite (with the optional backend of postgres) and the a bit more experimental mysql backend) I've set it up with a sqlite database... obviously this was not the best choice ;-) (I'll have a look how good the mysql backend is, as I've already a mysql server running). I hope this will fix this issue in the long term.. in the short term simply do a refresh of the site ;-) Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
Hey, - after some testing the branch with patch will deleted (and the ticket is closed) - if testing fail, create new branch with patch... hm, need to discuss this situation. See below my suggestion. This is pretty much the old stuff above (now we create a branch for every ticket (proposed branchname 1234_something_describing). BTW, may be a situation in which no one askes for the patch (no time or busy, lazy, don't want to take responsibility for the consequences of a patch, etc). What do in this case? Well.. if this will be the case in the future we have to rethink the idea.. but until at least 3 people are more or less active this shouldn't happen. And what do if no testing reports? Is ticket leave in 'always testing' stage? Okay to fasten the process a bit up: - if a ticket contains a patch the acceptor of this ticket create a branch with this patch applied - people can test it there and comment in this ticket - if they have an enhancment they can fix it in git (and push it to the server of course ;-)) and add a updated patch (for tracking the issue) to the bugreport. If the patch in it's latest version is acked the branch get merged back into the master branch. Then we have only one ack step and not two anymore. Now, how to handle the ticket states with this workflow: After a ticket is created it is new.. When someone accepts it it is set to accepted. When someone has a patch which is worth to be added to a git branch, this should be done. Then the ticket can be set to testing as this is currently the case (We test if the patch is okay). If two people acked the patch (they really should test it and not only look on the sourcecode), the branch with the fix inside will be merged by the acceptor of the ticket this branch belongs too, into master. Then the ticket will be set to closed. The same if we develop after 4.6.2 own new stuff: A ticket is opened with the idea inside... Someone develops a new feature based on master in a branch. After he thinks that this task is done he adds a patch to the report and set the report to testing. Then someone can look at his work and comment in the ticket. After the patch is fine this branch get merged into master (and the ticket is closed). Hope this helps to make it someone easier. Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
On Sun, Jan 04, 2009 at 09:28:29PM +0100, Patrick Winnertz wrote: ps: If this is okay I'll delete the stable branch and update/write a bit about this workflow to our wiki) delete *the* stable branch, but not the concept of stable branches per se. doing so would mean that once you merged a feature patch to master, you cannot do a bugfix release any more until you make a feature release (*). to keep the option of bugfix releases open (and distributors really want that), one should always make a release branch from master (say, 4.6) and branch for bugfix patches from that branch. then one can make a bugfix release (say, 4.6.3) from the 4.6 branch at any time. the release branch is merged into master (but not the other way round) after each fix. of course that requires upfront planning whether a particular patch needs to go into a possible bugfix release, but given the patch branch process, you have a good start for that (the proposal in your next mail seems reasonable). (*) actually, one can retroactively create a release branch from a past master revision on demand. anyway, that results in a mess, as the need for cherry picking is practically guaranteed in that case. on top of that, the release process as such becomes a mess (if a release branch exists, tag there, otherwise tag on master. think of this, don't forget that, and, oh, if you are religious: pray). ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: RFC: updated workflow [WAS: Re: git+patch workflow]
delete *the* stable branch, but not the concept of stable branches per se. doing so would mean that once you merged a feature patch to master, you cannot do a bugfix release any more until you make a feature release (*). to keep the option of bugfix releases open (and distributors really want that), one should always make a release branch from master (say, 4.6) and branch for bugfix patches from that branch. then one can make a bugfix release (say, 4.6.3) from the 4.6 branch at any time. the release branch is merged into master (but not the other way round) after each fix. of course that requires upfront planning whether a particular patch needs to go into a possible bugfix release, but given the patch branch process, you have a good start for that (the proposal in your next mail seems reasonable). This was the way I planned it actually before writting my email. After rethinking the stuff I thought it would also be possible to only work with master without having stable branches. The disadvantage is that a pure bugfix release won't be possible (since master is also used for development.) Okay as I think think this makes sense: [copy paste from a older mail]: - if a ticket contains a patch the acceptor of this ticket create a branch (*) with this patch applied - people can test it there and comment in this ticket - if they have an enhancment they can fix it in git (and push it to the server of course ;-)) and add a updated patch (for tracking the issue) to the bugreport. If the patch in it's latest version is acked the branch get merged back into the parent branch. Then we have only one ack step and not two anymore. (*): based on, wether it should be a bugfix for a stable tree, mc-4.6 or if it should be a new feature, on master. If created on a stable release branch this fix is also merged back after it is applied on the release branch into the master branch. Now, how to handle the ticket states with this workflow: After a ticket is created it is new.. When someone accepts it it is set to accepted. When someone has a patch which is worth to be added to a git branch, this should be done. Then the ticket can be set to testing as this is currently the case (We test if the patch is okay). If two people acked the patch (they really should test it and not only look on the sourcecode), the branch with the fix inside will be merged by the acceptor of the ticket this branch belongs too, into the appropiate branch (e.g. mc-4.6 or master). Then the ticket will be set to closed. The same if we develop after 4.6.2 own new stuff: A ticket is opened with the idea inside... Someone develops a new feature based on master in a branch. After he thinks that this task is done he adds a patch to the report and set the report to testing. Then someone can look at his work and comment in the ticket. After the patch is fine this branch get merged into master (and the ticket is closed). (*) actually, one can retroactively create a release branch from a past master revision on demand. anyway, that results in a mess, as the need for cherry picking is practically guaranteed in that case. on top of that, the release process as such becomes a mess (if a release branch exists, tag there, otherwise tag on master. think of this, don't forget that, and, oh, if you are religious: pray). This is a mess and was never intended :) Greetings Winnie -- . '' ` . Patrick Winnertz win...@debian.org : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~winnie - http://www.der-winnie.de `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
