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: 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
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: bundled intl stuff necessary
* Roland Illig roland.il...@gmx.de schrieb: Enrico Weigelt schrieb: Hi folks, is it necessary to have the intl lib bundled into mc or could it be taken directly from the system ? (I admit, I don't know much about how it really works ;-o) I don't think it is necessary. There are many other projects who have dropped the internal intl/ directory. Okay, I'm trying to hack up something. This will also be my first reallife learning experience w/ git ;-) Please give me some hint how to send back my changes for review (directly via git). 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: bundled intl stuff necessary
* Slava Zanko slavaza...@gmail.com schrieb:
Hi,
lib - in my mind must be sources of library(es) of project.
What we see in directory lib?
ACK. Currently, it contains lots of stuff which clearly don't belong
there, but instead something like man/doc/shared-data/whatever.
My purpose (in far-near future):
doc
man (current ${src_root}/doc)
contributor (contributor manuals)
developer (developers manual)
What exactly is the difference between developer and contributor ?
user (all README-files, readme about hotkeys, all other
user-related)
contrib
contrib/extfs (current ${src_root}/vfs/extfs)
Why do extfs scripts belong into contrib ?
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
The global menu configs belong into ${sysconfdir}/mc. Hintfiles
are locale stuff, so belong somewhere below ${datarootdir}/locale/ ..
contrib/lib (current ${src_root}/lib, except mc.hint.* and
README.xterm)
And the lib/ChangeLog should be merged with the one in the toplevel dir.
contrib/syntax (current ${src_root}/syntax)
Why are the syntaxfiles contrib stuff ?
lib/slang
Why should we carry an own branch of slang at all ?
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: bundled intl stuff necessary
On Sat, 3 Jan 2009 17:34:19 +0100 Enrico Weigelt wrote:
Why do extfs scripts belong into contrib ?
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
Why? ${datarootdir}/mc contains arch-independent files and
mc-specific files. It's correct place in terms of FHS.
The global menu configs belong into ${sysconfdir}/mc.
I agree.
Hintfiles are locale stuff, so belong somewhere below
${datarootdir}/locale/.
Hintfiles are private data of mc. ${datarootdir}/mc is correct place
for it.
--
Regards,
Andrew.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Enrico Weigelt wrote:
My purpose (in far-near future):
doc
man (current ${src_root}/doc)
contributor (contributor manuals)
developer (developers manual)
What exactly is the difference between developer and contributor ?
Developer docs:
- - style of project sources;
- - descriptions of internal functions (library related, may be via doxygen)
- - UML-like schemas... or in plain text :)
- - other doc-stuff related to developers
Contributor... gm... may be I'm mistaken with word... 'maintainer' more
like.
- - How make packages in rpm, deb, tgz(Slackware) and other
package-oriented distros
- - How compile on *BSD/MaCOS, Cygwin/MinGW
- - How compile on embedded systems
- - ... other maintainer-related stuff
contrib
contrib/extfs (current ${src_root}/vfs/extfs)
Why do extfs scripts belong into contrib ?
contrib/syntax (current ${src_root}/syntax)
Why are the syntaxfiles contrib stuff ?
this not a part of mc executable and must be in conrtib area, IMHO
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
The global menu configs belong into ${sysconfdir}/mc. Hintfiles
are locale stuff, so belong somewhere below ${datarootdir}/locale/ ..
This already applyed in Fedora-10 patch. Later I will publish this patch
in trac.
contrib/lib (current ${src_root}/lib, except mc.hint.* and
README.xterm)
And the lib/ChangeLog should be merged with the one in the toplevel dir.
ACK.
lib/slang
Why should we carry an own branch of slang at all ?
For embedded systems with less of memory, IMHO...
... P.S. May be, in future mc will work on my iPhone... ;)
WBR. Slavaz.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAklfmUYACgkQb3oGR6aVLponugCdGMWhLVP0yiEaaY0Ibgs6Gt34
4roAnRCOM49isy6Cs5qFSUZZBIlHPvgG
=OsnN
-END PGP SIGNATURE-
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
* Andrew Borodin aboro...@vmail.ru schrieb:
On Sat, 3 Jan 2009 17:34:19 +0100 Enrico Weigelt wrote:
Why do extfs scripts belong into contrib ?
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
Why? ${datarootdir}/mc contains arch-independent files and
mc-specific files. It's correct place in terms of FHS.
Are you *absolutely* sure they're always arch-independent and
ever will be ?
Hintfiles are locale stuff, so belong somewhere below
${datarootdir}/locale/.
Hintfiles are private data of mc. ${datarootdir}/mc is correct place
for it.
Yeah, same way private as .mo files, and they also serve almost
the purpose: language specific messages.
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: bundled intl stuff necessary
* Slava Zanko slavaza...@gmail.com schrieb:
Contributor... gm... may be I'm mistaken with word... 'maintainer' more
like.
- - How make packages in rpm, deb, tgz(Slackware) and other
package-oriented distros
- - How compile on *BSD/MaCOS, Cygwin/MinGW
- - How compile on embedded systems
- - ... other maintainer-related stuff
hmm, isn't that just normal doc stuff ? ;-o
(perhaps under the packager/ subdir)
Why do extfs scripts belong into contrib ?
contrib/syntax (current ${src_root}/syntax)
Why are the syntaxfiles contrib stuff ?
this not a part of mc executable and must be in conrtib area, IMHO
They're needed by mcedit at runtime, same as shared libs, configs, etc.
IMHO, contrib means: from external sources and not officially
maintained by the upstream. I don't see that we really have this
situation yet (besides distro-specific buildfiles, etc).
BTW: they should be installed into ${libexecdir}/mc, not
${datarootdir}/mc. Same w/ the stuff in ${datarootdir}/mc/bin.
The global menu configs belong into ${sysconfdir}/mc. Hintfiles
are locale stuff, so belong somewhere below ${datarootdir}/locale/ ..
This already applyed in Fedora-10 patch. Later I will publish this patch
in trac.
Ok.
lib/slang
Why should we carry an own branch of slang at all ?
For embedded systems with less of memory, IMHO...
Already suspected something like that. IMHO an stupid idea:
Embedded maintainers should use an trimmed-down slang or do
static linking, etc. BTW: the change of unnecessarily bloating
up the system w/ bundled slang is quite good - just takes one
more slang-using app and all benefit's gone.
My vote is to completely dropping the bundled slang and let the
embedded folks do the trim-down on their own.
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
git+patch workflow [WAS: bundled intl stuff necessary]
* 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. 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. 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 ? 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 ? 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: bundled intl stuff necessary
* Andrew Borodin aboro...@vmail.ru schrieb:
On Sat, 3 Jan 2009 18:14:21 +0100 Enrico Weigelt wrote:
* Andrew Borodin schrieb:
${datarootdir}/mc contains arch-independent files and
mc-specific files. It's correct place in terms of FHS.
Are you *absolutely* sure they're always arch-independent
At current time -- yes.
and ever will be ?
Who knows? :-)
That's the point. Some day someone writes an extfs in C (which
is evrything but improbable) and the hassle begins. I'd prefer
to keep such trouble out of the way even before it starts.
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: bundled intl stuff necessary
Enrico Weigelt schrieb: Hi folks, is it necessary to have the intl lib bundled into mc or could it be taken directly from the system ? (I admit, I don't know much about how it really works ;-o) I don't think it is necessary. There are many other projects who have dropped the internal intl/ directory. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bundled intl stuff necessary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Illig wrote:
Enrico Weigelt schrieb:
Hi folks,
is it necessary to have the intl lib bundled into mc or could it
be taken directly from the system ?
(I admit, I don't know much about how it really works ;-o)
I don't think it is necessary. There are many other projects who have
dropped the internal intl/ directory.
If we started to talk about the source tree...
What now:
config
doc
edit
lib
m4
maint
po
slang
src
syntax
vfs
I think, this not good.
lib - in my mind must be sources of library(es) of project.
What we see in directory lib?
doc - Documentation of project, included:
- - man pages
- - Users manual
- - Developers manual (doxygen?)
- - Maintainers manual (how make packages on all known OSes, for example)
Now in directory 'doc' only manpages... and README-files at all
subdirectoryes.
My purpose (in far-near future):
doc
man (current ${src_root}/doc)
contributor (contributor manuals)
developer (developers manual)
user (all README-files, readme about hotkeys, all other
user-related)
contrib
contrib/extfs (current ${src_root}/vfs/extfs)
contrib/hints
contrib/lib (current ${src_root}/lib, except mc.hint.* and
README.xterm)
contrib/maint (current ${src_root}/maint)
contrib/syntax (current ${src_root}/syntax)
lib
lib/edit (current ${src_root}/edit)
lib/mcglib (may be, needed as mcslang for embedded systems... Little
internal library... but it's only thinks)
lib/slang
lib/vfs
lib/vfs/samba
m4
po
src
WBR, Slavaz.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFJWzU2b3oGR6aVLpoRAhsuAJ914GDP2/6kAPx53GQgzQ86QBFLOQCfXupQ
2WJiflZRaGvsv7CY80Rt/TM=
=a/Gh
-END PGP SIGNATURE-
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
