The only issue left is the svn history. In my eyes, what we used mostly as commit messages is not really worth keeping. Even large feature commits have only one-liners, other commits change dozens of files with the only comment "minor changes". If one really want to benefit from the svn history, commit messages like this are as good as a blank message. While I ported the changes from krusader_kde3 (CVS) to krusader_kde4 (svn) the the history wasn't really helpful. In the future we may could dispence more self-discipline regarding the commit message, meaning: - no mass commits; one individual commit per feature/bugfix - meaningful and descriptive commit messages: one line short description one blank line several lines of details about the change (what, why, how it works, ...) - deprecate SVNNEWS (I know, this file was my idea, but it wasn't a good one ;-)). All the information needed by handbook writers or other developers/reviewers should be attached to the changeset itself, meaning in the commit messages. Even the ChangeLog could become obsolete by taking only the first lines from the commit messages.
So, my proposal: Import the 2.0.0 release (tags/krusader-2.0.0) and replay the remaining patches manually (6 for Csaba (code), 7 for Frank (handbook), 1 for Dirk (message merge will may be not needed any more)). If one really need access to earlier versions the full pre-2.0.0 history is still available at sourceforge.
What do you think? Should we contact the KDE guys again (in fact last time they contacted/invited us) to discuss a migration? In my eyes we can only benefit, esp. since the development has slow down a lot lately...
> The only issue left is the svn history. In my eyes, what we used
> mostly as commit messages is not really worth keeping. Even large
> feature commits have only one-liners, other commits change dozens of
> files with the only comment "minor changes". If one really want to
> benefit from the svn history, commit messages like this are as good as
> a blank message. While I ported the changes from krusader_kde3 (CVS)
> to krusader_kde4 (svn) the the history wasn't really helpful.
> In the future we may could dispence more self-discipline regarding the
> commit message, meaning:
> - no mass commits; one individual commit per feature/bugfix
> - meaningful and descriptive commit messages:
> one line short description
> one blank line
> several lines of details about the change (what, why, how it
> works, ...)
> - deprecate SVNNEWS (I know, this file was my idea, but it wasn't a
> good one ;-)). All the information needed by handbook writers or other
> developers/reviewers should be attached to the changeset itself,
> meaning in the commit messages. Even the ChangeLog could become
> obsolete by taking only the first lines from the commit messages.
> So, my proposal: Import the 2.0.0 release (tags/krusader-2.0.0) and
> replay the remaining patches manually (6 for Csaba (code), 7 for Frank
> (handbook), 1 for Dirk (message merge will may be not needed any
> more)). If one really need access to earlier versions the full
> pre-2.0.0 history is still available at sourceforge.
> What do you think? Should we contact the KDE guys again (in fact last
> time they contacted/invited us) to discuss a migration? In my eyes we
> can only benefit, esp. since the development has slow down a lot
> lately...
On Fri, May 1, 2009 at 12:20 AM, Jonas Bähr <jonas.ba...@web.de> wrote:
> Hi,
> Now that 2.0.0 is out of the door, what do you think of moving into > kde's svn now?
+1 Go for it
> - deprecate SVNNEWS (I know, this file was my idea, but it wasn't a > good one ;-)). All the information needed by handbook writers or other > developers/reviewers should be attached to the changeset itself, > meaning in the commit messages. Even the ChangeLog could become > obsolete by taking only the first lines from the commit messages.
I disagree about SVNNEWS and the Changelog. I don't want to check gazillion commit mails for small messages. I don't I have the time for it, and I sure I will miss many messages and so they will not be documented, so you will get a bad handbook.
With the Changelog file and SVNNEWS I only need to check 2 files. I also sure that the Changelog and SVNNEWS (latest news at the bleeding SVN edge) is useful for or many users (they will not check the commit mails).
So please keep the Changelog file and SVNNEWS file.
> So, my proposal: Import the 2.0.0 release (tags/krusader-2.0.0) and > replay the remaining patches manually (6 for Csaba (code), 7 for Frank > (handbook), 1 for Dirk (message merge will may be not needed any > more)). If one really need access to earlier versions the full > pre-2.0.0 history is still available at sourceforge.
Simply copy the handbook code to kde svn :)
About i18n for GUI and i18n documentation, does this go a separate i18n-package or not? This should be discussed.
btw. I runnend into some trouble with xml2po, po2xml for the French handbook, so I could use some help from kde i18n guys :)
>> - deprecate SVNNEWS (I know, this file was my idea, but it wasn't a
>> good one ;-)). All the information needed by handbook writers or
>> other
>> developers/reviewers should be attached to the changeset itself,
>> meaning in the commit messages. Even the ChangeLog could become
>> obsolete by taking only the first lines from the commit messages.
> I disagree about SVNNEWS and the Changelog.
> I don't want to check gazillion commit mails for small messages.
> I don't I have the time for it, and I sure I will miss many messages
> and so they will not be documented, so you will get a bad handbook.
> With the Changelog file and SVNNEWS I only need to check 2 files.
> I also sure that the Changelog and SVNNEWS (latest news at the
> bleeding SVN edge) is useful for or many users (they will not check
> the commit mails).
> So please keep the Changelog file and SVNNEWS file.
You don't need to dig though the mails, you only need to look at the
subversion log. If the handbook is up to date till revision 2655, you
only need to say
$ svn log -r2655:HEAD
and you get all the messages from revision 2655 till the latest. (I'm
sure kdesvn can do the same)
Regarding the website, it should be pretty easy to make the subversion
history available online in a little timeline.
The problem with a separate file is that this text is not related to
the actual changes anymore. If you want to connect them again, you
have to annotate the ChangeLog/SVNNEWS to find the commit which
changed these files, hoping that they where changed in the same commit
as the changes they describe, and then fetch the patch for this
revision. And since most of our commit messages give hardly any
information, you have to dig through this mailing list too, hoping
there was a discussion around the date of the commit... (the other way
round is even worse: you annotate a file to get information why a
certain line was changed and the whole info you get is "minor changes")
That's why I think it's absolutely necessary to connect the
information about some changes with the actual changes themselves;
else there isn't much value in a project's history.
>> So, my proposal: Import the 2.0.0 release (tags/krusader-2.0.0) and
>> replay the remaining patches manually (6 for Csaba (code), 7 for
>> Frank
>> (handbook), 1 for Dirk (message merge will may be not needed any
>> more)). If one really need access to earlier versions the full
>> pre-2.0.0 history is still available at sourceforge.
> Simply copy the handbook code to kde svn :)
> About i18n for GUI and i18n documentation, does this go a separate
> i18n-package or not? This should be discussed.
> btw. I runnend into some trouble with xml2po, po2xml for the French
> handbook,
> so I could use some help from kde i18n guys :)
> The only issue left is the svn history. In my eyes, what we used > mostly as commit messages is not really worth keeping. Even large > feature commits have only one-liners, other commits change dozens of > files with the only comment "minor changes". If one really want to > benefit from the svn history, commit messages like this are as good as > a blank message. While I ported the changes from krusader_kde3 (CVS) > to krusader_kde4 (svn) the the history wasn't really helpful. > In the future we may could dispence more self-discipline regarding the > commit message, meaning: > - no mass commits; one individual commit per feature/bugfix > - meaningful and descriptive commit messages: > one line short description > one blank line > several lines of details about the change (what, why, how it > works, ...) > - deprecate SVNNEWS (I know, this file was my idea, but it wasn't a > good one ;-)). All the information needed by handbook writers or other > developers/reviewers should be attached to the changeset itself, > meaning in the commit messages. Even the ChangeLog could become > obsolete by taking only the first lines from the commit messages.
> So, my proposal: Import the 2.0.0 release (tags/krusader-2.0.0) and > replay the remaining patches manually (6 for Csaba (code), 7 for Frank > (handbook), 1 for Dirk (message merge will may be not needed any > more)). If one really need access to earlier versions the full > pre-2.0.0 history is still available at sourceforge.
> What do you think? Should we contact the KDE guys again (in fact last > time they contacted/invited us) to discuss a migration? In my eyes we > can only benefit, esp. since the development has slow down a lot > lately...
> bye, > Jonas
+1 Yes. I think the time is right.
Krusader forever. Still the first thing I install on any distro that does not incorporate krusader on CD1.
> The only issue left is the svn history. In my eyes, what we used > mostly as commit messages is not really worth keeping. Even large > feature commits have only one-liners, other commits change dozens of > files with the only comment "minor changes". If one really want to > benefit from the svn history, commit messages like this are as good as > a blank message. While I ported the changes from krusader_kde3 (CVS) > to krusader_kde4 (svn) the the history wasn't really helpful. > In the future we may could dispence more self-discipline regarding the > commit message, meaning: > - no mass commits; one individual commit per feature/bugfix > - meaningful and descriptive commit messages: > one line short description > one blank line > several lines of details about the change (what, why, how it > works, ...) > - deprecate SVNNEWS (I know, this file was my idea, but it wasn't a > good one ;-)). All the information needed by handbook writers or other > developers/reviewers should be attached to the changeset itself, > meaning in the commit messages. Even the ChangeLog could become > obsolete by taking only the first lines from the commit messages.
> So, my proposal: Import the 2.0.0 release (tags/krusader-2.0.0) and > replay the remaining patches manually (6 for Csaba (code), 7 for Frank > (handbook), 1 for Dirk (message merge will may be not needed any > more)). If one really need access to earlier versions the full > pre-2.0.0 history is still available at sourceforge.
> What do you think? Should we contact the KDE guys again (in fact last > time they contacted/invited us) to discuss a migration? In my eyes we > can only benefit, esp. since the development has slow down a lot > lately...
> Dne pátek 01 květen 2009 Jonas Bähr napsal(a):
> > Hi,
> > Now that 2.0.0 is out of the door, what do you think of moving into
> > kde's svn now? In the tread started by Sebastian Krüger on 2008-11-25
> > [1] and Fathi Boudra on 2008-11-17 [2] I only saw positive feedback:
> > [1]
> > The only issue left is the svn history. In my eyes, what we used
> > mostly as commit messages is not really worth keeping. Even large
> > feature commits have only one-liners, other commits change dozens of
> > files with the only comment "minor changes". If one really want to
> > benefit from the svn history, commit messages like this are as good as
> > a blank message. While I ported the changes from krusader_kde3 (CVS)
> > to krusader_kde4 (svn) the the history wasn't really helpful.
> > In the future we may could dispence more self-discipline regarding the
> > commit message, meaning:
> > - no mass commits; one individual commit per feature/bugfix
> > - meaningful and descriptive commit messages:
> > one line short description
> > one blank line
> > several lines of details about the change (what, why, how it
> > works, ...)
> > - deprecate SVNNEWS (I know, this file was my idea, but it wasn't a
> > good one ;-)). All the information needed by handbook writers or other
> > developers/reviewers should be attached to the changeset itself,
> > meaning in the commit messages. Even the ChangeLog could become
> > obsolete by taking only the first lines from the commit messages.
> > So, my proposal: Import the 2.0.0 release (tags/krusader-2.0.0) and
> > replay the remaining patches manually (6 for Csaba (code), 7 for Frank
> > (handbook), 1 for Dirk (message merge will may be not needed any
> > more)). If one really need access to earlier versions the full
> > pre-2.0.0 history is still available at sourceforge.
> > What do you think? Should we contact the KDE guys again (in fact last
> > time they contacted/invited us) to discuss a migration? In my eyes we
> > can only benefit, esp. since the development has slow down a lot
> > lately...
On Sun, May 3, 2009 at 12:08 AM, Jonas Bähr <jonas.ba...@web.de> wrote:
> Hi,
> Am 02.05.2009 um 22:10 schrieb Frank Schoolmeesters: >> On Fri, May 1, 2009 at 12:20 AM, Jonas Bähr <jonas.ba...@web.de> >> wrote:
>>> Hi,
>>> Now that 2.0.0 is out of the door, what do you think of moving into >>> kde's svn now? >> +1 >> Go for it
> still waiting for more replies from other Krew members...
>>> - deprecate SVNNEWS (I know, this file was my idea, but it wasn't a >>> good one ;-)). All the information needed by handbook writers or >>> other >>> developers/reviewers should be attached to the changeset itself, >>> meaning in the commit messages. Even the ChangeLog could become >>> obsolete by taking only the first lines from the commit messages.
>> I disagree about SVNNEWS and the Changelog. >> I don't want to check gazillion commit mails for small messages. >> I don't I have the time for it, and I sure I will miss many messages >> and so they will not be documented, so you will get a bad handbook.
>> With the Changelog file and SVNNEWS I only need to check 2 files. >> I also sure that the Changelog and SVNNEWS (latest news at the >> bleeding SVN edge) is useful for or many users (they will not check >> the commit mails).
>> So please keep the Changelog file and SVNNEWS file.
> You don't need to dig though the mails, you only need to look at the > subversion log. If the handbook is up to date till revision 2655, you > only need to say > $ svn log -r2655:HEAD > and you get all the messages from revision 2655 till the latest. (I'm > sure kdesvn can do the same)
> Regarding the website, it should be pretty easy to make the subversion > history available online in a little timeline.
> The problem with a separate file is that this text is not related to > the actual changes anymore. If you want to connect them again, you > have to annotate the ChangeLog/SVNNEWS to find the commit which > changed these files, hoping that they where changed in the same commit > as the changes they describe, and then fetch the patch for this > revision. And since most of our commit messages give hardly any > information, you have to dig through this mailing list too, hoping > there was a discussion around the date of the commit... (the other way > round is even worse: you annotate a file to get information why a > certain line was changed and the whole info you get is "minor changes") > That's why I think it's absolutely necessary to connect the > information about some changes with the actual changes themselves; > else there isn't much value in a project's history.
> bye, > Jonas
Hi Jonas,
Even if I would use $ svn log -r2655:HEAD I guess 95% of the output will be pretty useless for me. patch, codechange, architecturechange, ... I don't think I will find a good description how a new feature will work.
I just want a short description of the new feature that the developers implement into Krusader, SVNNEWS and the Changelog is a perfect solution for it. Only the developer who has implemented a new features does 100% understand how a new feature works. I also don't have the time to play with new features. I even barely use LInux for the moment ... (sorry) mainly due lack of time (busy job, private live, ...) If the feature is not minimal documented by the developer, I can't write no good documention, and this woul be pitty. I agree for developer your method is needed, but not for writing documentation or inform users about new features. I usually don't need to know the SVN revision for the documentation, I just use the latest SVN.
I've done some experimentations with svk and wasn't able to migrate krusader svn to a svn local repository using svk.
Someone suggested to use tailor(1) and I'm mostly satisfied. It "replays" changesets from a vcs to another one.
It parses original changelog and produces a new changelog (to keep track of original author and timestamps): === e.g start === [krusader_kde4 @ 2472] added krusader_kde3 and named kde4 to start development
Original author: erlich Date: 2007-05-12 12:56:09.164807+00:00 === e.g stop ===
This way, history is kept: - each changeset is commited - original author is in the commit log - original date is in the commit log
Krusader will go to kdereview/krusader. The KDE build system and i18n people will probably check everything and make some adjustments after krusader import and announced it on kde-core-devel mailing list.
On Mon, May 25, 2009 at 4:57 PM, Fathi Boudra <fbou...@gmail.com> wrote:
> Hi,
> I've done some experimentations with svk and wasn't able to migrate > krusader svn to a svn local repository using svk.
> Someone suggested to use tailor(1) and I'm mostly satisfied. > It "replays" changesets from a vcs to another one.
> It parses original changelog and produces a new changelog (to keep track of > original author and timestamps): > === e.g start === > [krusader_kde4 @ 2472] > added krusader_kde3 and named kde4 to start development
> This way, history is kept: > - each changeset is commited > - original author is in the commit log > - original date is in the commit log
> Krusader will go to kdereview/krusader. > The KDE build system and i18n people will probably check everything > and make some adjustments after krusader import and announced it on > kde-core-devel mailing list.
I'm shure things about i18n the documentation should be discussed. I have a 98% translated French handbook, but runned into some trouble when generating the French docbook files. Unfurtunately due lack of (free Krusader) time, I don't have found the time yet to investigate this more. There are is also a partial Russinan translation of the handbook.
> I'm waiting for the green light to proceed.
I think there is one thing left for discussion. How we need to proceed to create a KDE SVN account for the Krew members + commit rights for the Krusader code ? If this is solved, then for me it's ok to proceed the move to kde svn, but the others of the Krew need to set the light on green as well.
FYI because I'm busy don't count on me for a few upcomming weeks
> I'm sure things about i18n the documentation should be discussed. > I have a 98% translated French handbook, but runned into some trouble > when generating the French docbook files. > Unfortunately due lack of (free Krusader) time, I don't have found the > time yet to investigate this more. > There are is also a partial Russinan translation of the handbook.
not sure I could take a look but I'll try.
> I think there is one thing left for discussion. > How we need to proceed to create a KDE SVN account for the Krew > members + commit rights for the Krusader code ?
To apply for KDE SVN account, go to https://sysadmin.kde.org/svnaccount/ and fill out the form. Indeed, the reason of account application is krusader.
After KDE SVN account creation, everybody can commit on KDE SVN.
After registration, you can get commit notification on KDE SVN. If someone wants to get only Krusader related changes, just filter Krusader path. The path must be adjusted after moving from kdereview to kde extragear.
> I've done some experimentations with svk and wasn't able to migrate
> krusader svn to a svn local repository using svk.
> Someone suggested to use tailor(1) and I'm mostly satisfied.
> It "replays" changesets from a vcs to another one.
> It parses original changelog and produces a new changelog (to keep
> track of
> original author and timestamps):
> === e.g start ===
> [krusader_kde4 @ 2472]
> added krusader_kde3 and named kde4 to start development
> This way, history is kept:
> - each changeset is commited
> - original author is in the commit log
> - original date is in the commit log
> Krusader will go to kdereview/krusader.
> The KDE build system and i18n people will probably check everything
> and make some adjustments after krusader import and announced it on
> kde-core-devel mailing list.
> I'm waiting for the green light to proceed.
green light from my side.
Thanks for pushing this forward!
On Tue, May 26, 2009 at 1:01 PM, Fathi Boudra <fbou...@gmail.com> wrote:
>> I'm sure things about i18n the documentation should be discussed. >> I have a 98% translated French handbook, but runned into some trouble >> when generating the French docbook files. >> Unfortunately due lack of (free Krusader) time, I don't have found the >> time yet to investigate this more. >> There are is also a partial Russinan translation of the handbook.
> not sure I could take a look but I'll try.
po2xml failed to create 100% correct French docbook files.
i18n-docs and 18n-GUI should be discussed anyway after the Krusader transfer to KDE SVN, because usually KDE uses separate i18N packages. Currently all Krusader-I18N is inside the Krusader code.
On Thursday 28 May 2009 13:45:09 Frank Schoolmeesters wrote:
> On Tue, May 26, 2009 at 1:01 PM, Fathi Boudra <fbou...@gmail.com> wrote: > >> I'm sure things about i18n the documentation should be discussed. > >> I have a 98% translated French handbook, but runned into some trouble > >> when generating the French docbook files. > >> Unfortunately due lack of (free Krusader) time, I don't have found the > >> time yet to investigate this more. > >> There are is also a partial Russinan translation of the handbook.
> > not sure I could take a look but I'll try.
> po2xml failed to create 100% correct French docbook files.
update_docbook script was broken. I fixed it.
Right now, I've got a failure on synchronizer.docbook: can't find A detailed explanation of all the functions and buttons is described in the following text. in detailed explanation of all the functions and buttons is described in the following text.</para>
Everything is in place from KDE side. The remaining issue is related to i18n stuff. imho, that' s not a blocker for the migration and KDE localisation team could help in this area. By the way, Krusader should stay in kdereview at least 2 weeks before moving to extragear and it should be enough to fix this issue.
I'll start the migration as nobody sent objections. I'll send a notification when it's done :)
I think we sould consider to close our SF Krusader bugtracker http://sourceforge.net/tracker/?atid=106488&group_id=6488&func=browse and start using the KDE bugtracker for Krusader. I suppose the Krew will need also the proper rights to close Krusader bugs in the KDE bugtracker.
btw. the KDE bugtracker was long time ago used for Krusader and might contain some old entries.
Am Samstag 30 Mai 2009 15:26:25 schrieb Frank Schoolmeesters:
> Hi all,
> I think we sould consider to close our SF Krusader bugtracker > http://sourceforge.net/tracker/?atid=106488&group_id=6488&func=browse > and start using the KDE bugtracker for Krusader. > I suppose the Krew will need also the proper rights to close Krusader > bugs in the KDE bugtracker.
> btw. the KDE bugtracker was long time ago used for Krusader and might > contain some old entries.
Heya,
please let me add here that i've been working on the new website again. As we decided to use trac, using a separate bugtracker would be counter productive. Trac is already running in the latest version on the server. Trac is going to replace all these services integrated smoothly in a single interface:
- bugtracker - svn browser (autosynced against a external svn repository) - wiki - todo list including voting (i've added a voting plugin)
Plus all the project management goodies provided by trac.
I know that i'm way behind my personal schedule, however since i'm getting paid to work with Python and Django now, it's much easier for me to finalize the website relaunch. I'm trying to get the relaunch done "this summer"!
On Sat, May 30, 2009 at 9:08 PM, Dirk Eschler <esch...@gmail.com> wrote:
> Am Samstag 30 Mai 2009 15:26:25 schrieb Frank Schoolmeesters: >> Hi all,
>> I think we sould consider to close our SF Krusader bugtracker >> http://sourceforge.net/tracker/?atid=106488&group_id=6488&func=browse >> and start using the KDE bugtracker for Krusader. >> I suppose the Krew will need also the proper rights to close Krusader >> bugs in the KDE bugtracker.
>> btw. the KDE bugtracker was long time ago used for Krusader and might >> contain some old entries.
> Heya,
> please let me add here that i've been working on the new website again. As we > decided to use trac, using a separate bugtracker would be counter productive. > Trac is already running in the latest version on the server. Trac is going to > replace all these services integrated smoothly in a single interface:
> - bugtracker > - svn browser (autosynced against a external svn repository) > - wiki > - todo list including voting (i've added a voting plugin)
> Plus all the project management goodies provided by trac.
> I know that i'm way behind my personal schedule, however since i'm getting > paid to work with Python and Django now, it's much easier for me to finalize > the website relaunch. I'm trying to get the relaunch done "this summer"!
> bye, > Dirk
Hi Dirk,
Great News!
I'm not sure if KDE people will use an "external" bugtracker, but personally I don't mind witch bugtracker is used.
> please let me add here that i've been working on the new website again. As > we decided to use trac, using a separate bugtracker would be counter > productive. Trac is already running in the latest version on the server. > Trac is going to replace all these services integrated smoothly in a single > interface:
when you say separate bugtracker, i guess you mean separate from the website/Trac.
> - bugtracker
I see a good point using KDE bug tracker: you can use special keywords in svn log messages.
I don't have a strong opinion on the different solutions (I'm a Trac fan) but the KDE bug tracker / svn integration is nice. Maybe that should be considered.
|
