Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On Mon, Jan 26, 2009 at 03:28, Martin Langhoff wrote: > On Sun, Jan 25, 2009 at 12:34 PM, Tomeu Vizoso wrote: >> You got distracted with shiny stuff! > > Rickrolled indeed :-) > >>> 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 >> >> We actually had it already, have updated the wiki page with info about it. >> >> http://sugarlabs.org/go/DevelopmentTeam/DatastoreRewrite > > Excellent news. Looks good (as described in the wikipage), so the > older datastores, having no 'version' file, are a nominal '0'. Yup. >> Sounds good, I guess you can do the reorg with hard links in the same >> script where we had the metadata exported to json. > > Exactly - guess what the client would have done, build an appropriate > hardlink tree, and then let rsync add/remove as appropriate. Avoids > transferring the actual data files which may be large. Sounds good. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On Sun, Jan 25, 2009 at 12:34 PM, Tomeu Vizoso wrote: > You got distracted with shiny stuff! Rickrolled indeed :-) >> 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 > > We actually had it already, have updated the wiki page with info about it. > > http://sugarlabs.org/go/DevelopmentTeam/DatastoreRewrite Excellent news. Looks good (as described in the wikipage), so the older datastores, having no 'version' file, are a nominal '0'. > Sounds good, I guess you can do the reorg with hard links in the same > script where we had the metadata exported to json. Exactly - guess what the client would have done, build an appropriate hardlink tree, and then let rsync add/remove as appropriate. Avoids transferring the actual data files which may be large. 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 16:42, Martin Langhoff wrote: > On Fri, Jan 23, 2009 at 4:22 PM, Tomeu Vizoso 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". You got distracted with shiny stuff! > 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 :-) Well, shipping the old DS wasn't really an option, so I had to go on with my work even if it risked being dumped further in the release cycle. > 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 We actually had it already, have updated the wiki page with info about it. http://sugarlabs.org/go/DevelopmentTeam/DatastoreRewrite > 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... Sounds good, I guess you can do the reorg with hard links in the same script where we had the metadata exported to json. Regards, Tomeu > 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 > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Sat, Jan 24, 2009 at 10:42 AM, Bernie Innocenti wrote: > Well, it's customary to introduce an additional state where the bug is > fixed in the developer's intentions, but not yet QA'd: > > NEW -> ASSIGNED -> FIXED -> CLOSED Bernie, 99% of my commits are "working on it, mate" ;-) It's not about turning the "quality knob", is about claiming that I "fix" or "close" something way before I know whether this commit fixes it or not. To recap: writing the commit msg happens very early in the process. Claiming to fix or close a bug at that time is... preposterous. I'll normally have tested it on my machine, but will ask the bug reporter to confirm it works for them and ask him/her to close the bug if they are happy with the fix. The Debian workflow, specially "Closes", is geared for the work of a _packager_, who is likely to be applying a well known and tested patch from upstream. So the packager can say with decent confidence "Closes". A packager that merges in new code and puts "closes" immediately in the changelog is acting blinded by his own ego. Given the track record of Debian, that is unlikely to happen :-) 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
Martin Langhoff wrote: > On Sat, Jan 24, 2009 at 6:39 AM, Bernie Innocenti 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. Well, it's customary to introduce an additional state where the bug is fixed in the developer's intentions, but not yet QA'd: NEW -> ASSIGNED -> FIXED -> CLOSED However, I'm not advocating for this just yet. Turn our quality knob up too much while our codebase is still a little immature and needs to change rapidly might even be counter-productive (i.e. project takes longer to reach stability). What's interesting about a "Closes:" (or "Fixes:") tag, is that it could be used to automatically close the bug in trac from the post commit hook, thus saving some precious time to our developers. > 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! Right, but who prepares the package changelog? If we're going to come up with something like the detailed Changelog that GNU coding practices demand, it's a lot of burden for very little value. The "humanized" release notes that Simon prepares, with reference to important bugs and new features, is ideal. A simple query in trac should be enough to find out what bugs were fixed between 0.42.1 and 0.42.2 if we care to add and maintain a "target milestone" field. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Sat, Jan 24, 2009 at 6:39 AM, Bernie Innocenti 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 Reviewed-by: Random J. Reader Tested-by: Random J. Tester Ack-by: Random J. Approver Cc: Random J. Developer 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/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On 23 Jan 2009, at 22:06, Gary Oberbrunner wrote: > Hi folks. I guess I'm somewhat confused with all the recent changes > taking place in the OLPC/Sugar world. I have an XO, and for a while I > was keeping up with all the latest joyrides. I think the last one I > installed was just before the old joyride branch went away some time > last year. Now there's a new joyride, but it's known not to be stable > enough for kid-friendly use, & that's fine. But there's also Sucrose > 0.83.4 which looks new & shiny. Can I install this on my XO (and > how), > or do I need to wait for a joyride build containing it? I.e. is > sucrose > an independently installable thing? Sorry to sound like such a newb. FWIW: I've been reasonably successfully running joyride 2631 on an XO for a few days now, and it seems to have all the 0.83.4 Sugar feature freeze changes in. Upgraded from an 8.2 (767) install so I'd have most activities, and get to test the migration from old data-store to new (i.e backup your important data, and don't expect to boot back to the old OS and still keep your old journal entries). Downloaded the .usb and .toc to a usb key, and then ran 'sudo olpc- update --usb' as per usual and rebooted. Then went about getting latest joyride flavour activities using 'wget' and 'sugar-install- bundle' (old browse-101 won't start, and control panel software-update doesn't...) Here's a list of recent .xo bundles you'll likely not have if you've just been using the CP software-updater: Write-61 (latest G1G1 is 60) http://shell.sugarlabs.org/~erikos/bundles/Write-61.xo Browse-103 (latest G1G1 is 101) http://shell.sugarlabs.org/~erikos/bundles/Browse-103.xo Calculate-28 (latest G1G1 is 25) http://people.sugarlabs.org/~rwh/Calculate/Calculate-28.xo Chat-62 (latest G1G1 is 48) http://dev.laptop.org/~morgan/bundles/Chat-62.xo Read-63 (latest G1G1 is 52) http://dev.laptop.org/~morgan/bundles/Read-63.xo Etoys-99 (latest G1G1 is 94) http://etoys.laptop.org/rpms/Etoys-99.xo TurtleArt-24 (latest G1G1 is 10) http://sugarlabs.org/wiki/images/b/b1/TurtleArt-24.xo Image Viewer (not part of G1G1) http://dev.laptop.org/~sayamindu/bundles/imageviewer/ImageViewer-5.xo Terminal-21 (18) http://dev.laptop.org/~sayamindu/bundles/terminal/Terminal-21.xo Jukebox-5 (not part of G1G1) http://dev.laptop.org/~kushal/Jukebox-5.xo You'll get to play/test new things like: - resume from home by default (BTW: it defaults to off) - activity name prompting when closing un-titled activities - new colour picker (Write) - Journal favourite filter - Access to XO home palette from your buddy icon in the frame Some obvious current pitfalls: - Mic light stays on all the time, very big brother ;-) - Software-updater... doesn't (and is pointing to the old G1G1 activity group anyway) - No working mesh network - Reasonably working AP network as long as you don't sleep/close-lid/ ctrl-alt-erase I've only just started finding/filling trac tickets for bugs I spot, would be great to get more of the braver XO owners doing the same. Also I'm sure feedback to the list about the new features would be very welcome, while there's still perhaps a little time to make refinements: http://dev.sugarlabs.org I think the plan of action from SugarLabs is to get the Sugar-on-a- Stick working well enough for XO owners, so we can try/test all the shiny new changes from a USB stick while keeping our existing release OS and data intact. So for the XO owning risk averse, it's probably worth waiting for an official announcement regarding SoaS. Happy testing! --Gary > -- > . . . . . . . . . . . . . . . . . . . . . . . . . > Gary Oberbrunnerga...@genarts.com > GenArts, Inc. Tel: 617-492-2888 > 955 Mass. Ave Fax: 617-492-2852 > Cambridge, MA 02139 USA www.genarts.com > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
Hi folks. I guess I'm somewhat confused with all the recent changes taking place in the OLPC/Sugar world. I have an XO, and for a while I was keeping up with all the latest joyrides. I think the last one I installed was just before the old joyride branch went away some time last year. Now there's a new joyride, but it's known not to be stable enough for kid-friendly use, & that's fine. But there's also Sucrose 0.83.4 which looks new & shiny. Can I install this on my XO (and how), or do I need to wait for a joyride build containing it? I.e. is sucrose an independently installable thing? Sorry to sound like such a newb. -- . . . . . . . . . . . . . . . . . . . . . . . . . Gary Oberbrunnerga...@genarts.com GenArts, Inc. Tel: 617-492-2888 955 Mass. Ave Fax: 617-492-2852 Cambridge, MA 02139 USA www.genarts.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] [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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 10:45 AM, Bernie Innocenti 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 4:22 PM, Tomeu Vizoso 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 16:17, Martin Langhoff wrote: > On Fri, Jan 23, 2009 at 4:04 PM, Tomeu Vizoso 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 > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 4:04 PM, Tomeu Vizoso 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 15:56, Martin Langhoff wrote: > On Wed, Jan 21, 2009 at 7:28 PM, Simon Schampijer 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
On Wed, Jan 21, 2009 at 7:28 PM, Simon Schampijer 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] [Sugar-devel] [ANNOUNCE] Sucrose 0.83.4 Development Release
On Fri, Jan 23, 2009 at 13:22, Simon Schampijer wrote: > Marco Pesenti Gritti wrote: >> On Fri, Jan 23, 2009 at 10:45 AM, Bernie Innocenti >> 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] [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/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jan 22, 2009 at 09:54:36AM +0100, Simon Schampijer wrote: >So the command for sugar for this release would be [...]: > >git log v0.83.4..v0.83.5 --no-merges | git-shortlog > >That will encourage people to write nice commit messages :) I would >suggest to put up some guidelines (no rules), so a reader can more >easily parse them. For example: > >- ticket number always at the beginning of the commit message >- Start message with a capital letter >- For typo fixes use: _Typo >- For pylint fixes use: _Pylint 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. - 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) iEYEARECAAYFAkl4irQACgkQn7DbMsAkQLgCDQCbBObD5vCNDLrGX3HNLNK1RvFg vokAniZd0hz/KXxZ2JhUf1Fr8s6me++e =4VCG -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
Bernie Innocenti wrote: > Walter Bender wrote: >> Wow!! > > We have great release notes lately. > > To credit authors, I'd also append the patch summary by author, > Linus-style. It can quickly be obtained this way: > > git log v0.83.3..HEAD | git-shortlog Excellent, will do that for the next release. So the command for sugar for this release would be (no-merges to get rid of the messages when you merge the master tree "Merge branch 'master' of gitori...@git.sugarlabs.org:sugar/mainline"): git log v0.83.4..v0.83.5 --no-merges | git-shortlog That will encourage people to write nice commit messages :) I would suggest to put up some guidelines (no rules), so a reader can more easily parse them. For example: - ticket number always at the beginning of the commit message - Start message with a capital letter - For typo fixes use: _Typo - For pylint fixes use: _Pylint More thoughts? Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] [ANNOUNCE] Sucrose 0.83.4 Development Release
Walter Bender wrote: > Wow!! We have great release notes lately. To credit authors, I'd also append the patch summary by author, Linus-style. It can quickly be obtained this way: git log v0.83.3..HEAD | git-shortlog -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] Sucrose 0.83.4 Development Release
Wow!!
-walter
On Wed, Jan 21, 2009 at 1:28 PM, Simon Schampijer wrote:
> Dear Sugar Community,
>
> Since, this date is Feature, API and String freeze everyone was busy
> getting their features in.
>
> From a user point of view we want to highlight the following:
>
> === Naming alert on journal entry creation ===
> The journal's search and browsing capabilities are less useful if all
> entries are named the same regardless of their actual content or
> meaning to the user. That is why an alert has been added that encourage
> the user to set the title and other properties, like available in the
> journal detail view, of a newly created journal entry. This alert is
> only shown on the creation of a new journal entry, not on resume.
>
> === Display recent activities in the home view ===
> In order to make easier to continue past work, the home view will
> display recent entries in the activity palettes.
>
> You can decide if you want the activity icons to represent the last
> journal entry with a new setting in the favourites view palette:
>
> === 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.
>
> A favourite filter has been added to the journal toolbar to give a
> better way of marking entries as 'important'. More regression fixes went
> into the support of removable devices after moving from maintaining an
> index file on the device to the use of POSIX calls.
>
> === New ColorToolButton Widget ===
> Benjamin Berg added a new ColorToolButton widget. It is already in use
> in the Write activity to select a colour for the text.
>
> === Control Panel===
> The 'About my XO' section has been renamed to 'About my Computer' to
> reflect the use of Sugar on non-XO hardware. Morgan Collett added the
> possibility to change the jabber server without restarting Sugar.
>
> === Autoconnect to Access Point ===
> NetworkManager does autoconnect on Sugar startup to the last Access
> Point you were connected successfully to.
>
> === Logout Option ===
> Sayamindu Dasgupta added a logout option to the xomenu. Eben Eliason
> added the accessibility of the xomenu to the groups and mesh view and to
> the friends tray in the frame.
>
> === New Logic for the devices positions ===
> The logic to position the frame devices has been reworked. Plug in your
> devices and try it out.
> [500 external devices eg. USB drive]
> [400 3rd party devices eg. speech]
> [300 transient connection devices eg. AP]
> [200 transient devices eg. camera]
> [100 static devices eg. battery]
>
> === Table of Content Support in Read ===
> The Read activity now shows the Table of Content for PDF files which
> support this feature. This eases navigation of large PDF files considerably.
>
> === Acknowledgment ===
> A big thanks goes to all the translators, that are working so hard to
> make Sugar a terrific localized environment and the infrastructure team
> that provides our members with tools and services to make their live easier.
>
>
> Thanks everyone for your great contributions!
>
> You can find more details and screenshots at
> [1] http://sugarlabs.org/go/DevelopmentTeam/Release/Releases/Sucrose/0.83.4
>
> The Sucrose Release Schedule can be found here
> [2] http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap#Schedule
>
>
> In behalf of the sugar community,
>Your Release Team
>
> _
>
> == Glucose news ==
>
> === sugar-toolkit ===
> * separate debug settings from xsession {{Bug|163}}
> * show an alert on activity close for suggesting the user to set
> properties of the entry {{Bug|215}}
> * add a colorpicker to Sugar, only the ColorToolButton is public for now
> * move the palette to new style gobject properties
> * {{OlpcBug|3060}} Add the possibility of filtering the object chooser
> by data type
> * fix uninstallling of activities that use symlinks {{Bug|171}}
> * remove the hacks for asking the X server for screenshots and use
> gtk.Widget.get_snapshot() instead
>
> === sugar ===
> * make the journal entries in the favorites palette resumable
> * simplify the constants used to identify favorite layouts
> * separate debug settings from xsession {{Bug|163}}
> * add logout option {{Bug|207}} to xomenu (sayamindu, icon by eben)
> * change jabber server without sugar restart {{Bug|142}}
> * About my XO -> About my Computer
> * {{Bug|196}} Fix setting the timezone in debian
> * autoconnect to AP that we connected to last {{Bug|8}}
> * add a favorites mode setting for deciding if the favorites view
> resumes by default or not
> * resume by default the last activity from the favorites view
> * implement filtering by file type for removable devices
> * {{Bug|132}} Filter by timestamp, not by mtime
> * add support for text queries on removable devices
> * dont abort if we cannot read a file from a removable device
> * add a favorite filter to the journal toolbar
> *
[ANNOUNCE] Sucrose 0.83.4 Development Release
Dear Sugar Community,
Since, this date is Feature, API and String freeze everyone was busy
getting their features in.
From a user point of view we want to highlight the following:
=== Naming alert on journal entry creation ===
The journal's search and browsing capabilities are less useful if all
entries are named the same regardless of their actual content or
meaning to the user. That is why an alert has been added that encourage
the user to set the title and other properties, like available in the
journal detail view, of a newly created journal entry. This alert is
only shown on the creation of a new journal entry, not on resume.
=== Display recent activities in the home view ===
In order to make easier to continue past work, the home view will
display recent entries in the activity palettes.
You can decide if you want the activity icons to represent the last
journal entry with a new setting in the favourites view palette:
=== 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.
A favourite filter has been added to the journal toolbar to give a
better way of marking entries as 'important'. More regression fixes went
into the support of removable devices after moving from maintaining an
index file on the device to the use of POSIX calls.
=== New ColorToolButton Widget ===
Benjamin Berg added a new ColorToolButton widget. It is already in use
in the Write activity to select a colour for the text.
=== Control Panel===
The 'About my XO' section has been renamed to 'About my Computer' to
reflect the use of Sugar on non-XO hardware. Morgan Collett added the
possibility to change the jabber server without restarting Sugar.
=== Autoconnect to Access Point ===
NetworkManager does autoconnect on Sugar startup to the last Access
Point you were connected successfully to.
=== Logout Option ===
Sayamindu Dasgupta added a logout option to the xomenu. Eben Eliason
added the accessibility of the xomenu to the groups and mesh view and to
the friends tray in the frame.
=== New Logic for the devices positions ===
The logic to position the frame devices has been reworked. Plug in your
devices and try it out.
[500 external devices eg. USB drive]
[400 3rd party devices eg. speech]
[300 transient connection devices eg. AP]
[200 transient devices eg. camera]
[100 static devices eg. battery]
=== Table of Content Support in Read ===
The Read activity now shows the Table of Content for PDF files which
support this feature. This eases navigation of large PDF files considerably.
=== Acknowledgment ===
A big thanks goes to all the translators, that are working so hard to
make Sugar a terrific localized environment and the infrastructure team
that provides our members with tools and services to make their live easier.
Thanks everyone for your great contributions!
You can find more details and screenshots at
[1] http://sugarlabs.org/go/DevelopmentTeam/Release/Releases/Sucrose/0.83.4
The Sucrose Release Schedule can be found here
[2] http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap#Schedule
In behalf of the sugar community,
Your Release Team
_
== Glucose news ==
=== sugar-toolkit ===
* separate debug settings from xsession {{Bug|163}}
* show an alert on activity close for suggesting the user to set
properties of the entry {{Bug|215}}
* add a colorpicker to Sugar, only the ColorToolButton is public for now
* move the palette to new style gobject properties
* {{OlpcBug|3060}} Add the possibility of filtering the object chooser
by data type
* fix uninstallling of activities that use symlinks {{Bug|171}}
* remove the hacks for asking the X server for screenshots and use
gtk.Widget.get_snapshot() instead
=== sugar ===
* make the journal entries in the favorites palette resumable
* simplify the constants used to identify favorite layouts
* separate debug settings from xsession {{Bug|163}}
* add logout option {{Bug|207}} to xomenu (sayamindu, icon by eben)
* change jabber server without sugar restart {{Bug|142}}
* About my XO -> About my Computer
* {{Bug|196}} Fix setting the timezone in debian
* autoconnect to AP that we connected to last {{Bug|8}}
* add a favorites mode setting for deciding if the favorites view
resumes by default or not
* resume by default the last activity from the favorites view
* implement filtering by file type for removable devices
* {{Bug|132}} Filter by timestamp, not by mtime
* add support for text queries on removable devices
* dont abort if we cannot read a file from a removable device
* add a favorite filter to the journal toolbar
* sanitize the file name when we copy to removable devices
* {{Bug|36}} Refresh the detailed view when the entry changes
* {{Bug|38}} Refresh full metadata when editing so we dont lose properties
* Focus Search is not exposed via dbus anymore {{Bug|8
