moving Krusader to kde's extragear?
Jonas Bähr
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] http://groups.google.com/group/krusader-devel/browse_thread/thread/af257ebed4d14260
[2] http://groups.google.com/group/krusader-devel/browse_thread/thread/0269d7beceff3274
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
shie erlich
especially that i'm one of the reasons development slowed down :-(
Fathi Boudra
> Now that 2.0.0 is out of the door, what do you think of moving into
> kde's svn now ?
+1
As suggested by David Faure, we should be able to migrate history using svk.
cheers,
Fathi
Frank Schoolmeesters
>
> Hi,
>
> Now that 2.0.0 is out of the door, what do you think of moving into
> kde's svn now?
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 :)
Thanks and bye,
Frank
Jonas Bähr
Am 02.05.2009 um 22:10 schrieb Frank Schoolmeesters:
> On Fri, May 1, 2009 at 12:20 AM, Jonas Bähr <jonas...@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.
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
Jonas Bähr
For archeological purpose the history is still available at sourceforge.
Anyway, a quick google gave me this:
http://stream.btucker.org/post/11864404/using-svk-to-migrate-stuff-between-svn-repositories
http://www.opentaps.org/docs/index.php/How_to_use_SVK
However, as far as I know subversion, this will lose the timestamp as
well as the original author of the changesets, won't it?
bye,
Jonas
> cheers,
>
> Fathi
>
>
> >
Richard/g
+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.
regards,
Richard.
Fathi Boudra
> For archeological purpose the history is still available at sourceforge.
I take a look and see the procedure with KDE sysadmins.
That's doesn't mean it's the green light yet :)
cheers,
Fathi
Václav Jůza
Dne pátek 01 květen 2009 Jonas Bähr napsal(a):
Rafi Yanai
Frank Schoolmeesters
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.
Thanks and bye,
Frank
Fathi Boudra
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.
I'm waiting for the green light to proceed.
cheers,
Fathi
Frank Schoolmeesters
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
Thanks a lot and bye,
Frank
> cheers,
>
> Fathi
>
Fathi Boudra
> I have a 98% translated French handbook, but runned into some trouble
> when generating the French docbook files.
> 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.
A service to know is KDE Commit notification filter:
http://commitfilter.kde.org
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.
cheers,
Fathi
Jonas Bähr
Thanks for pushing this forward!
bye,
Jonas
>
>
> cheers,
>
> Fathi
>
> >
Václav Jůza
green light from my side as well.
Thanks,
Vaclav
Dne úterý 26 květen 2009 Jonas Bähr napsal(a):
> Hi,
>
> Am 25.05.2009 um 16:57 schrieb Fathi Boudra:
> > Hi,
> > ...
Frank Schoolmeesters
>
>> 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.
Fathi Boudra
> On Tue, May 26, 2009 at 1:01 PM, Fathi Boudra <fbo...@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>
Fathi Boudra
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 :)
cheers,
Fathi
Fathi Boudra
> when it's done :)
It's done :) The migration was done successfully. Krusader in now in kdereview.
Krusader for KDE4 development started at r2472, commited under KDE svn
as r974546:
http://websvn.kde.org/?view=rev&revision=974546
Krusader svn last commit is r6310, commited under KDE svn as r975314:
http://websvn.kde.org/?view=rev&revision=975314
It should be announced on kde-core-devel mailing list.
I could announced it on behalf of the Krusader crew, just let me know.
cheers,
Fathi
Dirk Eschler
Heya Fathi,
thanks for pushing this in the right direction. I'd appreciate if you could do
the announcement.
bye,
Dirk
--
Dirk Eschler <esc...@gmail.com>
http://www.krusader.org
Frank Schoolmeesters
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.
Dirk Eschler
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"!
Frank Schoolmeesters
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.
Thanks and bye,
Frank
Fathi Boudra
> 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.
http://techbase.kde.org/Policies/SVN_Commit_Policy#Special_keywords_in_SVN_log_messages
especially:
BUG: can close directly the bug
CCBUG: cc your commit message to the bug
> - svn browser (autosynced against a external svn repository)
the service is provided by websvn.kde.org
> - wiki
> - todo list including voting (i've added a voting plugin)
> Plus all the project management goodies provided by trac.
these are new features.
There's also a possibility to use more KDE insfrastructure:
krusader.kde.org ? (afaik php can be used)
mailing list (krus...@kde.org)
wiki.kde.org e.g. http://wiki.kde.org/tiki-index.php?page=KPhotoAlbum
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.
cheers,
Fathi
Dirk Eschler
> Hi,
Hi Fathi,
> > 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.
Jup.
> > - bugtracker
>
> I see a good point using KDE bug tracker: you can use special keywords in
> svn log messages.
>
> http://techbase.kde.org/Policies/SVN_Commit_Policy#Special_keywords_in_SVN_
>log_messages
>
> especially:
> BUG: can close directly the bug
> CCBUG: cc your commit message to the bug
That's indeed a nice feature.
> > - svn browser (autosynced against a external svn repository)
>
> the service is provided by websvn.kde.org
>
> > - wiki
> > - todo list including voting (i've added a voting plugin)
> > Plus all the project management goodies provided by trac.
>
> these are new features.
>
> There's also a possibility to use more KDE insfrastructure:
> krusader.kde.org ? (afaik php can be used)
> mailing list (krus...@kde.org)
> wiki.kde.org e.g. http://wiki.kde.org/tiki-index.php?page=KPhotoAlbum
Actually one of the reasons to start a website rewrite from scratch was to get
away from PHP. ;) The new website is purely Python and Django (besides the
forum where no good Python alternative exists IMHO).
It's all in place, but i haven't found time to finalize it. Trac integrates
seemless into the website. You can have a look at it at
http://trac.krusader.org/ if you like. You should be a able log in with your
forum account, i've written a custom auth backend to authenticate against
phpbb from django. Note that you have to enter it more than once, as each
subdomain involved is protected at the moment.
Fathi Boudra
> seemless into the website.
I'm completely convinced by a website using Trac.
My concern is more focused on the bug tracker/subversion integration.
cheers,
Fathi
Karai Csaba
where can I commit my changes?
In KDE or in sourceforge?
Thanks,
Csaba
Fathi Boudra írta:
Fathi Boudra
> where can I commit my changes?
> In KDE or in sourceforge?
in KDE.
You should request an account first:
https://sysadmin.kde.org/svnaccount/
cheers,
Fathi
shie erlich
Karai Csaba
I've committed a prototype for Lister to the KDE repository.
I also noticed, that the code was reogranized (#include changes).
Please let me know if my changes are correct.
What is Lister:
- it is designed for viewing huge files without loading them to memory
- lister is not intended to replace the current viewers. Lister will
only be used if the file is bigger than a certain limit (such as 10
MBytes), and loading the file to the memory is not desired.
Lister never loads the whole file to memory,its behaviour:
FILE * file = fopen( "FileName.txt", "r" );
fseek( file, position, SEEK_SET );
fread( cache, cache_size, 1, file );
fclose( file );
I've tried viewing a 600 MByte text file, and it was as fast as viewing
a 10-kbyte file.
It's just a prototype in the repository, many things has to be fixed /
implemented until the final version.
Thanks,
Csaba
Fathi Boudra
> Please let me know if my changes are correct.
I've done the includes fixes.
It's still a work in progress and expect to review all files asap.
bye.
Fathi
Dirk Eschler
> a. mazal tov to all for the stepb. dirk: i can't wait to see you site. i've
> been working with python/django as well and love it
Heya Shie,
yeah Django rocks. You can watch my progress below
http://django.krusader.org/. Don't be scared about all these apache auth
popups, each subdomain is protected separately at the moment and they share
some css. You can use your forum login to get around them (if my custom auth
backend works properly).
I've been working daily on the new website within the last few days/weeks.
Being a superuser, you should also be able to use the website's trac instance.
There are two trac instances - one for krusader and one for the website. Just
in case you want to peek at the code or open tickets. ;-)
http://trac2.krusader.org/
Again, use your phpBB user credentials to log in.
Frank Schoolmeesters
I have just noticed that some KDE guys are fixing the English handbook
+ some i18N fixes so that xml2po will work better.
http://websvn.kde.org/trunk/kdereview/doc/krusader/
Thank you all guys !
Frank