Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
Jonas Smedegaard wrote: Use the recommended style as mentioned in Git documentation somewhere: First line a summary of at most 40 chars, then empty line, then optional detailed commit message (which is stripped by git-shortlog). Also, I'd suggest mentioning ticket numbers at end instead, in the style used by Debian. Example: Fix foobar - barbaz. Closes: SL#1234, OLPC#1235. The logic is to always prepend Closes: and then either SL# or # for each comma-separated ticket closed, or prepend OLPC# for tickets closed at the laptop.org bugtracker. Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. - The leading dot at the end should not be included because it looks super ugly in the subject of an email. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. Do we have a wiki page where we can document these practices? -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 10:45 AM, Bernie Innocenti ber...@codewiz.org wrote: Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. - The leading dot at the end should not be included because it looks super ugly in the subject of an email. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. Do we have a wiki page where we can document these practices? Perhaps http://sugarlabs.org/go/DevelopmentTeam/Git Marco ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
Marco Pesenti Gritti wrote: On Fri, Jan 23, 2009 at 10:45 AM, Bernie Innocenti ber...@codewiz.org wrote: Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. - The leading dot at the end should not be included because it looks super ugly in the subject of an email. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. Do we have a wiki page where we can document these practices? Perhaps http://sugarlabs.org/go/DevelopmentTeam/Git Marco Thanks for all your comments. I have put up http://sugarlabs.org/go/DevelopmentTeam/Git#Git_commit_message_guidelines reflecting the discussion. Nothing set in stone yet, feel free to comment or change in the next days - otherwise it will become mandatory ;) Cheers, Simon ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 13:22, Simon Schampijer si...@schampijer.de wrote: Marco Pesenti Gritti wrote: On Fri, Jan 23, 2009 at 10:45 AM, Bernie Innocenti ber...@codewiz.org wrote: Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. - The leading dot at the end should not be included because it looks super ugly in the subject of an email. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. Do we have a wiki page where we can document these practices? Perhaps http://sugarlabs.org/go/DevelopmentTeam/Git Marco Thanks for all your comments. I have put up http://sugarlabs.org/go/DevelopmentTeam/Git#Git_commit_message_guidelines reflecting the discussion. Nothing set in stone yet, feel free to comment or change in the next days - otherwise it will become mandatory ;) Sounds excellent to me. Regards, Tomeu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Wed, Jan 21, 2009 at 7:28 PM, Simon Schampijer si...@schampijer.de wrote: === Journal === Tomeu Vizoso has been doing a wonderful work of bringing the journal implementation closer to it's design.The Object chooser can now be filtered by data type. Cool, between this and the note mentioning the old datastore will be updated to the new format I wonder if the datastore storage - on disk - has changed significantly. I am thinking of ds-backup interoperation. Right now ds-backup uses the json-formatted metadata files, as well as the proper stored files. Any changes in those need a matching change on ds-backup code, probably just on the server-side code. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 15:56, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Jan 21, 2009 at 7:28 PM, Simon Schampijer si...@schampijer.de wrote: === Journal === Tomeu Vizoso has been doing a wonderful work of bringing the journal implementation closer to it's design.The Object chooser can now be filtered by data type. Cool, between this and the note mentioning the old datastore will be updated to the new format I wonder if the datastore storage - on disk - has changed significantly. I am thinking of ds-backup interoperation. Right now ds-backup uses the json-formatted metadata files, as well as the proper stored files. Any changes in those need a matching change on ds-backup code, probably just on the server-side code. Yeah, I recommend rsync'ing the ~/.sugar/default/datastore dir, maybe skipping the index subdir. You have the layout explained here: http://sugarlabs.org/go/DevelopmentTeam/DatastoreRewrite Regards, Tomeu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 4:04 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Yeah, I recommend rsync'ing the ~/.sugar/default/datastore dir, maybe skipping the index subdir. You have the layout explained here: http://sugarlabs.org/go/DevelopmentTeam/DatastoreRewrite Uhmmm. Ok, then I'll have to rework the server side too. Keep me in the loop with these things ;-) http://dev.laptop.org/ticket/9209 the backup infra will need a bit of work to handle this gracefully for example when clients get upgraded. The data files have moved, which means that unless we do something smart, rsync will try and resend everything. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 16:17, Martin Langhoff martin.langh...@gmail.com wrote: On Fri, Jan 23, 2009 at 4:04 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Yeah, I recommend rsync'ing the ~/.sugar/default/datastore dir, maybe skipping the index subdir. You have the layout explained here: http://sugarlabs.org/go/DevelopmentTeam/DatastoreRewrite Uhmmm. Ok, then I'll have to rework the server side too. Keep me in the loop with these things ;-) I actually would have appreciated more feedback when I asked for it some months ago. Anyway, I trust this layout change will simplify things for you at the end. Regards, Tomeu http://dev.laptop.org/ticket/9209 the backup infra will need a bit of work to handle this gracefully for example when clients get upgraded. The data files have moved, which means that unless we do something smart, rsync will try and resend everything. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 4:22 PM, Tomeu Vizoso to...@sugarlabs.org wrote: I actually would have appreciated more feedback when I asked for it some months ago. Anyway, I trust this layout change will simplify things for you at the end. Sorry, I probably hid at the sight of Journal rewrite proposal. There were several in the air. The changes you have made are good, I just didn't know that one of the journal reimplementations had actually gone ahead :-) Is it possible for you to add a single file that says the journal storage version at the root of it? Something like $ cat .sugar/default/datastore/store/format 2 That would make things a ton easier for ds-backup. ds-backup client can read that file and tell the server that it's a format 2 backup, so the server can re-org the files before the client rsyncs across... Without something like that, an upgrade to a new format in a large school would swamp RF for days... m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jan 23, 2009 at 10:45:15AM +0100, Bernie Innocenti wrote: Jonas Smedegaard wrote: Use the recommended style as mentioned in Git documentation somewhere: First line a summary of at most 40 chars, then empty line, then optional detailed commit message (which is stripped by git-shortlog). Also, I'd suggest mentioning ticket numbers at end instead, in the style used by Debian. Example: Fix foobar - barbaz. Closes: SL#1234, OLPC#1235. The logic is to always prepend Closes: and then either SL# or # for each comma-separated ticket closed, or prepend OLPC# for tickets closed at the laptop.org bugtracker. Some thoughts: - Because the commit message summary appears in the shortlog, it should be kept below 74 characters to avoid ugly wrapping. Git prepends commit hashes, which is the reason for keeping it even shorter. I do not remember where I read it but am pretty sure their recommendation is to keep first line at most 40 chars. - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. It really makes better sense to me to not squeeze bug hints into that first line at all, but instead include them in a later line of the commit. Dropping the leading Closes: makes it harder to rely on for automated bug closing. You might not care about that, but I must say that I find that mechanism pretty cool on Debian. - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. You mean that you agree with my proposal of having SL _optional_ or you mean that it must never be there? Imagine a future fork of Sugarlabs. Let's call it Suguntu to hint at where I am going with this. Suguntu has their own bug tracking system, and some Sugarlabs developers gets hired to work on both systems in parallel. In the beginning Suguntu acts as downstram to Sugarlabs, but over time some parts of Sugar then gets primarily maintained at Suguntu so some changelog entries close Suguntu bugreports and not Sugarlabs ones. I'd say it makes sense to allow SL as a hint, but just have it be optional so that for packages only maintained upstream at Sugarlabs there is no need to add it to eah and eery bug hint. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl6DCsACgkQn7DbMsAkQLgoMQCfdkb5ic6AZh0qcgWwKW6uJscy rtgAmQFGsA8+aqVq/NARmOj1LrMd0dN0 =51oi -END PGP SIGNATURE- ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] [OLPC library] bookrea...@lists.laptop.org , collaborations with the gnubook project
Dear all, We are working with the gnubook developers to help optimize it for reading books on the XO. Back in November, the majority of the discussion in the OLPC Library list concerned what the OLPC did (plus descriptions thereof). Since then, discussion has been much about __non-OLPC__ capabilities such as bookreader and gnubook. From what I can gather, these are Web services (though suited for children's use) -- which I prefer to access from a display physically larger than what the OLPC provides. What I have done for myself is install on my XO as many *programs* for ebook reading as I could find (FBReader, Adobe Reader, jbook reader, etc). Plus I have an SD card in my XO to which I save the texts that I access with those programs. Then I can use the XO for what it was designed for - to read books in places where there is *no* web connectivity. If all you are discussing is how to use a browser -- then there is no specific need for an XO to be involved. mikus ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [OLPC library] bookrea...@lists.laptop.org , collaborations with the gnubook project
Mikus, Some readers are mainly accessed online, but a reader is not a 'web' service per se, it is an interface. Now it's true that every interface is a service of a sort... I could host an fbreader instance for you, but that wouldn't change anything. Comparing fbreader with a standalone gnubook instance (say by adding gnubook support to evince, which we are considering), and with the current Read activity (which should be more flexible than just a pdf reader to live up to its name, and read all formats), is a pertinent subject to address. I think it likely that the best readers will not require the overhead of a browser, but there are certain advantages to readers that work the same online and off. SJ On Fri, Jan 23, 2009 at 5:55 PM, Mikus Grinbergs mi...@bga.com wrote: Dear all, We are working with the gnubook developers to help optimize it for reading books on the XO. Back in November, the majority of the discussion in the OLPC Library list concerned what the OLPC did (plus descriptions thereof). Since then, discussion has been much about __non-OLPC__ capabilities such as bookreader and gnubook. From what I can gather, these are Web services (though suited for children's use) -- which I prefer to access from a display physically larger than what the OLPC provides. What I have done for myself is install on my XO as many *programs* for ebook reading as I could find (FBReader, Adobe Reader, jbook reader, etc). Plus I have an SD card in my XO to which I save the texts that I access with those programs. Then I can use the XO for what it was designed for - to read books in places where there is *no* web connectivity. If all you are discussing is how to use a browser -- then there is no specific need for an XO to be involved. mikus ___ Library mailing list libr...@lists.laptop.org http://lists.laptop.org/listinfo/library ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Fwd: Call for Speakers at FOSSVT 2009
We will have a Sugar session. Hopefully we can get a donation of USB sticks and give them out for people to collaborate during the conference. Let me know if you can come. Thanks, Caroline -- Forwarded message -- From: Bryant Patten fos...@ncose.org Date: Fri, Jan 23, 2009 at 2:53 PM Subject: Call for Speakers at FOSSVT 2009 To: Caroline Meeks carol...@solutiongrove.com, walter.ben...@gmail.com ** Vermont's Premier Open Source and Education Conference is seeking presentations for the Friday April 10th, 2009 gathering. ** We are soliciting presentations for (and from) teachers, administrators and technology people on the topic of Free and Open Source Software in K-12 schools. We are also soliciting SUGGESTIONS for sessions - so if you have an Open Source/Free Software topic you would like to learn about, let us know and we will see if we can find someone to speak on that subject at the conference. If you would like to present, or have a presentation idea, please contact us at: fos...@ncose.org Earlybird registration will open on February 1st. See you April 10th! Bryant Patten FOSSVT Conference Coordinator -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
Jonas Smedegaard wrote: - Given the above, the word Closes: steals precious characters, and is rather easy to deduce, therefore I'd opt it out. It really makes better sense to me to not squeeze bug hints into that first line at all, but instead include them in a later line of the commit. Dropping the leading Closes: makes it harder to rely on for automated bug closing. You might not care about that, but I must say that I find that mechanism pretty cool on Debian. If the Closes: line is going to be part of the long description, then I totally agree we should use it. I'd even propose the adoption the other conventional headers used by the Linux kernel community: Signed-off-by: Random J. Hacker r...@example.org Reviewed-by: Random J. Reader r...@example.org Tested-by: Random J. Tester r...@example.org Ack-by: Random J. Approver r...@example.org Cc: Random J. Developer r...@example.org The semantics are described here: http://lxr.linux.no/linux+v2.6.28.1/Documentation/SubmittingPatches#L377 - To reduce clutter, I'd make the SL prefix implied, and leave other prefixes such as OLPC#123 and RH#456 explicit. You mean that you agree with my proposal of having SL _optional_ or you mean that it must never be there? Imagine a future fork of Sugarlabs. Let's call it Suguntu to hint at where I am going with this. Suguntu has their own bug tracking system, and some Sugarlabs developers gets hired to work on both systems in parallel. In the beginning Suguntu acts as downstram to Sugarlabs, but over time some parts of Sugar then gets primarily maintained at Suguntu so some changelog entries close Suguntu bugreports and not Sugarlabs ones. I'd say it makes sense to allow SL as a hint, but just have it be optional so that for packages only maintained upstream at Sugarlabs there is no need to add it to eah and eery bug hint. I meant it should have been optional, but if we switch to using the Closes: header in the body, where we have no size constraints, then we could has well use the prefix consistently. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Sat, Jan 24, 2009 at 6:39 AM, Bernie Innocenti ber...@codewiz.org wrote: I meant it should have been optional, but if we switch to using the Closes: header in the body, where we have no size constraints, then we could has well use the prefix consistently. One important note WRT 'Closes'... Code hits git way earlier than it hits the package. So in most projects where I work, people will put in the commit msg a bugnumber, meaning that it's _related_ to that bug. To say it 'closes' the bug denotes a confidence I rarely have when working with the SCM. Once it's tested, and everyone's happy, the new release gets packaged, and we can say - with more confidence - that it closes some bugs. For example I have done series of 100+ patches related to one bug. None of them closed it, but once the new (major) release was ready, the package changelog did say Closes: #123. What's good for packaging... is good for packaging! cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
