Re: Nine Months in Six Months
В Сбт, 09/09/2006 в 04:55 +0200, BJörn Lindqvist пишет: > On 9/8/06, Don Scorgie <[EMAIL PROTECTED]> wrote: > > Doc people do not have enough time. Its as simple as that. As shaunm > > pointed out, this release we got 4 weeks to update the documentation. > > This included 3 new modules needing docs, as well as lots of updates to > > lots of other docs. The doc team has been on skeleton staff ever since > > I've known it. Most of the docs are now pretty out of date. Add in a > > desire to have translated docs and basically, the doc team has negative > > time to do the required work. The great part about it is that for the > > other 5 months, the doc team is pretty much sitting around, twiddling > > thumbs and thinking up plans for world domination [1]. The writers > > can't really do their thing with a moving target. > > Then lets stop the target! If I understand you correctly, the > development process from the documentors point of view is kind of like > this. > > * Five months were developers play and pretty much destroy all the docs we > make. > * Four weeks were we can undo the damage caused and make GNOME understandable. > > Maybe this problem can be solved by elevating the documentations and > the translations status in the project? For example, patches are very > seldom accepted if they introduce regressions in the software. But > regressions in the docs aren't counted in the same way. New code very > often changes applications behaviour so that the manual becomes > invalid. What if the documentation and translation regressions were > counted in the same way as code regressions? > > To me, that makes sense. An untranslated string is just as annoying as > a frequently segfaulting program. So lets treat the problems the same. > Code that changes behaviour shouldn't be committed unless the > documentation is updated. User visible strings shouldn't be changed > unless the translations are updated. Something like that? > Exactly, and although it's a not reasonable to wait for translations update as Adam pointed, C locale documentation should be updated by change author. As for translations we don't have much problem with them now, when we support more than 40 languages. Moreover, I think we need more polices and guidelines like HIG. There should be API guideline (I don't quite understand all those statements that we now know how good API look, today callbacks are used instead of signals often and it's certainly not a good way of writing API). We need a testing guideline (and a test violation should be considered as a regression and reverted without discussion). As mentioned above, maintainers should provide their roadmap while branching. It was good tradition in previous cycles, but now I've seen a lot of project branched without providing any future plans. It would be nice to get updates of already submitted plans, how many points are finished and how many points are shifted to the next release cycle. For example, what's the state of this list: http://live.gnome.org/GnomeArchitecture/Progress We must document design decisions when they are made. Documentation should include arguments and decisions made. GEP http://developer.gnome.org/gep/gep-0.html was the greates thing here and I wonder why it's not used now It may restrict our freedom, but only this way can do big changes and assure quality. signature.asc Description: Эта часть сообщения подписана цифровой подписью ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 BJörn Lindqvist wrote: > To me, that makes sense. An untranslated string is just as annoying as > a frequently segfaulting program. So lets treat the problems the same. > Code that changes behaviour shouldn't be committed unless the > documentation is updated. User visible strings shouldn't be changed > unless the translations are updated. Something like that? I agree with the first part because updating the C locale documentation should be doable by any programmer capable of changing the behavior of the documented program. However, any programmer doesn't have the capability of updating all of the translations. I think that requiring translated strings before a check-in then becomes an onerous task. Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net http://live.gnome.org/Seahorse -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAjoqjU1oaHEI4wgRAu0CAJ9Bm7qPH9ASsHQKqIl+/BGp6jycYACg3Lx4 yY9XL5Ce+rIyZo+taIQvfRY= =3scE -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On 9/8/06, Don Scorgie <[EMAIL PROTECTED]> wrote: > Doc people do not have enough time. Its as simple as that. As shaunm > pointed out, this release we got 4 weeks to update the documentation. > This included 3 new modules needing docs, as well as lots of updates to > lots of other docs. The doc team has been on skeleton staff ever since > I've known it. Most of the docs are now pretty out of date. Add in a > desire to have translated docs and basically, the doc team has negative > time to do the required work. The great part about it is that for the > other 5 months, the doc team is pretty much sitting around, twiddling > thumbs and thinking up plans for world domination [1]. The writers > can't really do their thing with a moving target. Then lets stop the target! If I understand you correctly, the development process from the documentors point of view is kind of like this. * Five months were developers play and pretty much destroy all the docs we make. * Four weeks were we can undo the damage caused and make GNOME understandable. Maybe this problem can be solved by elevating the documentations and the translations status in the project? For example, patches are very seldom accepted if they introduce regressions in the software. But regressions in the docs aren't counted in the same way. New code very often changes applications behaviour so that the manual becomes invalid. What if the documentation and translation regressions were counted in the same way as code regressions? To me, that makes sense. An untranslated string is just as annoying as a frequently segfaulting program. So lets treat the problems the same. Code that changes behaviour shouldn't be committed unless the documentation is updated. User visible strings shouldn't be changed unless the translations are updated. Something like that? -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On Fri, 2006-09-08 at 01:00 -0500, Shaun McCance wrote:
>
> Here is my much-anticipated MASTER PLAN:
>
> Using my incredible mathematical genius, I have figured
> out how to fit an entire nine months of work into only
> six months. I knew there was a reason I got a degree
> in mathematics. (Or at least, I could, if I'd just pay
> Purdue that pesky $40 I owe them.)
>
> http://www.gnome.org/~shaunm/ninebysix.html
There are really two problems faced by the doc team:
Problem the first:
Doc people do not have enough time. Its as simple as that. As shaunm
pointed out, this release we got 4 weeks to update the documentation.
This included 3 new modules needing docs, as well as lots of updates to
lots of other docs. The doc team has been on skeleton staff ever since
I've known it. Most of the docs are now pretty out of date. Add in a
desire to have translated docs and basically, the doc team has negative
time to do the required work. The great part about it is that for the
other 5 months, the doc team is pretty much sitting around, twiddling
thumbs and thinking up plans for world domination [1]. The writers
can't really do their thing with a moving target.
Problem the second:
The doc team is pretty ostracised from the general GNOME developer
community. We (okay, shaunm) have tried to fix this for as long as I've
been around, but developers prefer to spend their time working on new
pretty or quashing bugs. Doc people are generally fairly far down the
list of priorities.
(and yes, this is a real problem)
The "9x6" proposal helps address the first problem pretty well. At no
point in the cycle are the doc people nor the devs sitting around
twiddling thumbs and planning world domination [2].
Addressing the second problem is more ... problematic. As I said,
shaunm's been trying to fix this for years. There are plans afoot to
try and fix this, but unless we have more time to write the docs,
getting our profile raised won't really have much impact [3].
So, to summarise: Doc team need more time. 6x9 proposal provides that.
If another proposal were to be ... proposed [4] that granted the doc
team more time than currently, but also solved the issues raised in all
the other posts in this thread, I'd be right behind it. As of now
though, the 6x9 seems the best option anyone's suggested (including the
current schedule) [5].
Seconds out... Round four...
Don
[1] Want to plot world domination? Join the GNOME doc team today!
[2] Okay, negative impact on world domination front, positive impact on
GNOME. Most of the plans we thought up were pretty pants anyway and
seemed to involve the use of sheep too much
[3] I can imagine it'd just piss people off tbh. "Ugh. Another email
from the doc people. Why bother responding, its not like {I use the
docs | they do anything with the stuff I send | they've even looked at
the docs for my module in 3 years}"
[4] I'm not at my most eloquent today.
[5] With my doc team hat on, but also my developer hat - 7 months of
hacking in the release cycle!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Fri, 2006-09-08 at 10:17 +0200, Rodrigo Moya wrote: > On Thu, 2006-09-07 at 13:56 -0400, Pat Suwalski wrote: > > Hubert Figuiere wrote: > > > I would like to suggest at one point to try to break with the 6 month > > > release > > > schedule of Gnome to do a "major" release with a certain number of > > > feature > > > that would involve possible infrastructure changes in the platform. > > > > I have been thinking about this as well, just from observing how "shit > > hits the fan" near the end of the cycle. > > > > I'd like to throw out a suggestion that perhaps GNOME should alternate > > on a six-month-twelve-month release cycle, regardless of "major release" > > or not. It might make planning a little more complicated, but I'm sure > > it would be appreciated by developers and users alike. > > > I think 12 months is too much time. And if we need to do a major > release, we can, for instance, branch now for gnome-2-18, do there only > minor bugfixes and small feature additions for the upcoming 2-20 and, at > the same time, dedicate the 12 months (2-18 + 2-20) to work on HEAD for > the major release. > > That is, there is nothing in the schedule preventing us from working on > a major release for 1/1.5 years while at the same time keeping up with > the 6-month release cycle. This is pretty much always given as the reason why longer cycles aren't needed. And what it completely fails to address is the issue of non-programmer contributors. As a programmer, I can absolutely get myself ten straight months of unbridled hacking time by skipping a release. In fact, I've done it once before with Yelp. But the documentation team still only gets six weeks. Not only that, they now have six weeks to document everything you were able to change in ten months. Programmers are the only people who can take advantage of this. Nobody else can. The documentation team can't just sit out a release cycle and force the programmers to keep their modules static while we do so. We need more expert reviews (accessibility, user interface, strings), more testing, and more documentation work. That means more time. And if we ever hope to have translated documentation, the documentation team needs to finish even earlier, so the translators have a chance. The documentation team can't conceivable consider anything finished until after the UI and string freezes. In 2.16, that gave us four weeks. Now let's try to finish two weeks early to give translators a sporting chance. That gives us two weeks. Two weeks to document whatever programmers can manage to do in four to five months. That's insane. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
James Henstridge wrote: > On 08/09/06, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote: >> Your master plan implies branching early and heavily committing to >> both branches for a long time. Reality check: we are still using this >> archaic software called C.V.S.! Branching with that software is >> incredibly complex. >> >> Your master plan is blocked by bug #: "migration to >> subversion". > > The real issue with handling development in parallel branches is > really complexity of merging. This is an area where Subversion > doesn't really buy you much over CVS -- you still need to manually > keep track of what you merged to do a repeated merge. Actually, what would be great is to have a SCM that allows cherry-picking of patches (like git and mercurial I think). This allow to backport useful patches very easily if apply clean changesets. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On Fri, 2006-09-08 at 11:18 +0100, Gustavo J. A. M. Carneiro wrote: > On Sex, 2006-09-08 at 01:00 -0500, Shaun McCance wrote: > > On Thu, 2006-09-07 at 19:32 +0100, Don Scorgie wrote: > > > Hi, > > > > > > On Thu, 2006-09-07 at 11:24 -0700, David Trowbridge wrote: > > > > What in particular isn't possible with the 6-month cycle? > > > > > > For one thing: the documentation gets squeezed. We (the doc team) have, > > > basically, 3 month to document all the changes, update all the docs and > > > add any new documentation needed. The doc team is currently running at > > > skeleton staff and is working right up until the tarball submission > > > deadline. This knocks on and means that the doc translations (if > > > present) are invariably a release behind. > > > > > > Don > > > /me now waits to see if shaunm will release his top-secret plan for > > > world domination... > > > > Here is my much-anticipated MASTER PLAN: > > Your master plan implies branching early and heavily committing to > both branches for a long time. Reality check: we are still using this > archaic software called C.V.S.! Branching with that software is > incredibly complex. > > Your master plan is blocked by bug #: "migration to > subversion". I don't really think the concurrency issues will be problematic. Look at it this way: My schedule gives developers four months or so before feature freeze. This is roughly what they have now. It then gives them two months before we really lock things down. That's six months, a period of time developers are used to. Currently, this is where developers would release a premature .0 tarball, and move on with the next cycle. They might do bug fixes on the stable branch. Meanwhile, writers and translators continue to do stuff to the stable branch, because hey, what the hell else are we going to do? If maintainers are following the rules, they'll release a .1 and a .2 release sometime later. They will do this even if there were no code changes, because writers and translators have done work. The big thing I'm changing is what we call that tarball that we release after six months. Right now we call it 2.18.0. I propose we call it 2.17.6. Then we take the release we'd currently call 2.18.2 and call it 2.18.0 instead. The main point is this: there are multiple efforts that go into creating our software. Many of these efforts work independently of each other. Most of the non-programmer efforts have to occur after we've let the programmers have their fun time. So let's make our schedule reflect that natural state of things. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Thu, 2006-09-07 at 12:59 -0400, Hubert Figuiere wrote: > I would like to suggest at one point to try to break with the 6 month release > schedule of Gnome to do a "major" release with a certain number of feature > that would involve possible infrastructure changes in the platform. > Not sure whether the situations are similar, but I don't think this went well for Ubuntu. In hind sight, I don't believe there was much of a benefit of stretching the dapper release cycle by 6 weeks. We got 6 more weeks of bug fixing, sure, but we also got 6 more weeks of bug development. The fact is that whatever your release cycle length, things always fall in the same places. What would work better would be if features were actively developed for the 2.20 release at the same time as things were being developed for the 2.18 release, so that the release schedule remains the same but the development focus can be different. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
The Lower Desktop, Upper Desktops
*The Lower Desktop, Upper Desktops* (a letter to the Gnome community, in a poor English) It was about two years while I was more or less in touch with Gnome, and I must say that no other large free software project delivers so much confusion to an outsider. And since Gnome has always been my favourive desktop, I feel obligatory to share with the Gnome community my thoughts that were inspired by some recent posts on d-d-l. Many users and developers agree that Free Desktops have some deep yet obscure problems. Sometimes they call a freedom of desktop choice with a depressed “pick up your poison” phrase. Although everybody agree that troubles exist, a quick look at Gnome 3.0 plans reveals that there is no clear formulation of those troubles, not to say about solutions to them. I have no necessary experience neither authority to point Gnome new directions, instead I want to continue a somewhat radical “rehash” of certain Free Desktop traditions. This process is already going on with the help of freedesktop.org, and the noble purpose of this message is an attempt to fasten it. The Ideal Vision The ideal vision is a dream... We live in the ideal world that has no troubles. We have an invincible free kernel and a number of sublime desktops that can satisfy every user on the planet. Every such a desktop represent some ideology: one – configurability, another – simplicity, third – lighweightness. All desktops are built on top of a pool of common technologies. It's better to split desktop user-base into two categories: developers and ordinary users. Let's call desktop technologies a “Lower Desktop” and desktops for users – “Upper Desktops”. The Lower Desktop has everything for developers to create an Upper Desktop of their choice. The Lower Desktop is a technology, it has no ideology. An Upper Desktop is an ideology, it has no technology. What parts do the Lower Desktop and Upper Desktops consist of? The Lower Desktop: windowing system, configuration database, MIME database, virtual file-system, IPC, component technology, file formats, language run-times, etc. Toolkits are also here. A toolkit is a Lower Desktop abstraction that makes multi-platform (multi-desktop) development possible. A toolkit provides not only desktop abstractions (widgets and a browser window) but kernel abstractions also (threading, fast low-level I/O). Toolkits use the same look-and-feel engine. An Upper Desktop targets certain user audience by providing user-visible applications that meat well-defined criterion. The range of those applications is limited only by Upper Desktop's ideology: from panels, applets and basic set of utilities to office suites, browsers and advanced administrative tools. An Upper Desktop is also a certification authority – an intermediary that guarantees the user that an application from independent developers satisfies desktop's ideology. Artifacts of the Past = Due to historical reasons Gnome (as well as KDE) is a mixture of both Lower and Upper Desktop concepts. I dare to say that such complex constructs if not reformed will only stagnate and collapse in the long run. However not all is that bad, some smart people founded freedesktop.org – something missing from Day One but now acting like an anchor in unsettled desktop waters (a truthful panegyric). Freedesktop.org is the Lower Desktop, a foundation for Upper Desktops. Keeping in mind the ideal vision described in previous passages it is now possible to deduce problems of Upper Desktops and suggest solutions. I am not familiar with Gnome internals so I want to leave this task to the Gnome community (if the community is not distracted by my “mental experiments”), but some points I want to mention here myself. As said, I am not familiar with Gnome internals, yet some things are pretty obvious, even at unconsciousness level. You probably remember “Mono Debate” - an epic tragicomedy of inclusion a C# runtime into Gnome. I suppose it is now evident why that culmination of absurd did not happen: a language run-time position is the lowest in the technology stack. (I want to add that existence of Mono is very important to free software, but this is a separate topic.) And the last: the mixture of technology and ideology slowly transforms Gnome from a software project into a political union of several forces (ranging from FOSS powers to individuals) who play this meritocracy game: make-contribution-gain-leverage. Instead of being a community of friends pursuing shared goals, Gnome is turning into a Wild West, a dangerous place where every contributor is being treated as an aggressor despite of his intentions. This is being done unconsciously because you have no leadership, beware! Instead of a happy-end: - GTK+ and its wrappers belong to Lower Desktop (freedesktop.org) - GnomeVFS and GConf belong to Lower Des
Re: The future of session management in GNOME
Hi, > * XSMP does a number of useful session-managey things (logout > notification, logout cancellation, specifying apps that > should be restarted right away if they crash, specifying > commands to run at logout, etc) which we currently have no > other way of doing, so we'd be forced to reinvent half of > XSMP if we ditched it. So at this point I'm sort of of the opinion that logout cancellation isn't really useful. Apps should just be saving their state all along the way. This is interesting for other cases, too, like if the power goes out. In general, I don't think people should ever lose work, and having this "save everything that's still open when the user just wants to get out the door" step isn't really the right way to go about it. I know this is punting the hardest part of the problem to every app though. > * To reduce the number of special case hacks the session > manager contains for various bits of GNOME functionality, > we'll add a way for autostarted programs to make changes to > the session manager's environment; eg, setting GTK_MODULES > for a11y, So for this one, we should just switch over to using gtksettings instead of environment variables. >setting G_DEBUG for unstable-series testing, > setting GNOME_KEYRING_SOCKET for the keyring manager, > etc--currently these are all done as special cases in > gnome-session. The clients would work like ssh-agent (print > out a few VARIABLE=value lines at startup and then fork or > exit), and there would be a new autostart .desktop property > indicating that the client behaves this way. The session > manager would start them, read their stdout, run the > appropriate putenv()s, and continue starting things up. Sounds reasonable enough...my only concern is that apps tend to spew things to the console without really realizing it. > We could make the splash screen a separate program too. > (Would this actually be useful?) The session manager has > .desktop files for everything it's starting, so it could > just do startup notification when it launches them, and then > the splash screen program could watch that to see what > icons/localized app names to put up. (We'd also need to have > the session manager signal somehow when the splash screen > should go away.) Do we even need a splash screen? Soeren turned if off by default in fedora. > * The session management UI will be more icon-y and less > command-line-y than it is now. (The session manager will > hopefully have a .desktop file for each app, so it can use > those to get icons and localized names.) It will probably > communicate with the session manager via dbus, rather than > using kludgey hacks on top of XSMP. That sounds good. One conclusion I came to the other day about gnome-session-properties: It has three tabs. The first one isn't really useful at all, the second one should be merged into gnome-system-monitor, and the third one is the only one that really seems interesting. Maybe it should just be gnome-startup-programs? > Of course we'll want to throw away the gnome-session codebase > completely. (If you disagree, please go read the code.) The best bet > would probably be to rewrite it in C#. I'm kidding. I'M KIDDING! The > "msm" module that Havoc started several years ago and Ray Strode > continued hacking on a bit later is probably a good starting point for > a new session manager. If you start with that, make sure you rip out DSME bits. That spec never went anywhere. > We also want a better client API than GnomeClient. GnomeClient is a > very very thin layer around XSMP, mostly because when it was written > there wasn't enough agreement about what certain parts of XSMP meant, > so it was impossible to abstract/simplify the API. As mentioned > before, this is somewhat fixed now[3], so we can make a nicer API > based on our new understanding. At the very least we want separate > "save_state" (Local SaveYourself) and "save_files" (Global > SaveYourself) signals, rather than a generic "save_yourself" signal > with 36 possible combinations of flags where almost every single app > in jhbuild that uses GnomeClient implements only one behavior that it > uses regardless of the flags passed (and often that behavior is not > 100% correct for any of the 36 possibilities). msm has a client library, too, that Havoc was working on at one point. It's probably too lowlevel, too, though. > So I'm volunteering to do all of this: > > * Write up a more detailed proposal than the above > > * Propose extensions to fdo autostart spec, and a spec > covering the XSMP extensions and clarifications. (Hopefully > the XSMP stuff could
Re: Planning Gnome Scan Inclusion
You are welcome... -Joseph == On Fri, 2006-09-08 at 16:51 +0200, Étienne Bersac wrote: > Hi, > > > Thanks... I will try it out this weekend. If all goes well, I will add > > it to GARNOME so others can play with it an provide feedback. > > Wow ! Nice ! Thank you ! :D > > Étienne. -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Fri, 2006-09-08 at 14:44 +1000, Andrew Cowie wrote: > The people I work with on java-gnome won't be able to hack on GNOME 2.16 > specific bindings until we have GNOME 2.16 desktops on our systems. My > systems are otherwise production (in the sense that I use them to do > business so I can't afford to have them hideously broken With jhbuild or similar, there's no need to install experimental stuff system-wide. Just a create a development sandbox and use it to write the bindings. -- Bye, -Torsten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning Gnome Scan Inclusion
Hi, > Thanks... I will try it out this weekend. If all goes well, I will add > it to GARNOME so others can play with it an provide feedback. Wow ! Nice ! Thank you ! :D Étienne. -- Verso l'Alto ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Elijah Newren wrote: > I used to be firmly in favor of the 6-month cycle, but I found > Andrew's argument quite convincing and it has turned me into more of a > fence sitter for now. It isn't yet clear to me that a change would be > a definite improvement, let alone enough of a benefit to merit the > change in the process, but that may well change. I think this is why an alternating 6 and 12 month cycle would be nice. A 9 month cycle would be even more interesting, because the dates would not always fall at the same times. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning Gnome Scan Inclusion
Thanks... I will try it out this weekend. If all goes well, I will add it to GARNOME so others can play with it an provide feedback. -Joseph == On Fri, 2006-09-08 at 16:15 +0200, Étienne Bersac wrote: > Hello, > > > Where is the source??? > > I pointed the current projet homepage : > http://home.gna.org/gnomescan/index . Follow the "projet page" link and > you'll be lead to SVN. You can also use tarballs from > http://home.gna.org/gnomescan/download . > > However, i released a 0.2.3 (including deutsch translation). All files > are at http://download.gna.org/gnomescan . > > Étienne. -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning Gnome Scan Inclusion
Hello, > Where is the source??? I pointed the current projet homepage : http://home.gna.org/gnomescan/index . Follow the "projet page" link and you'll be lead to SVN. You can also use tarballs from http://home.gna.org/gnomescan/download . However, i released a 0.2.3 (including deutsch translation). All files are at http://download.gna.org/gnomescan . Étienne. -- Verso l'Alto ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning Gnome Scan Inclusion
Where is the source??? -Joseph === On Fri, 2006-09-08 at 15:45 +0200, Étienne Bersac wrote: > Hello, > > > I am curious to know what the word "flegita" means. Searches using > > google and dictionaries in three languages didn't turn up anything which > > looked relevant. > > Good question. :) flegita is an esperanto word that mean "cured". > > Étienne. > -- > Verso l'Alto ! > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On 08/09/06, Hubert Figuiere <[EMAIL PROTECTED]> wrote: > On Friday 08 September 2006 08:57, James Henstridge wrote: > > The real issue with handling development in parallel branches is > > really complexity of merging. This is an area where Subversion > > doesn't really buy you much over CVS -- you still need to manually > > keep track of what you merged to do a repeated merge. > > Yet another piece or urban legend. > Obviously you have never used the command svnmerge (now part of the svn > package). > http://www.dellroad.org/svnmerge/index That software just automates the task of recording where you have merged up to, which is not particularly sophisticated. I used a similar script when maintaining the Gnome customisations of ViewCVS on cvs.gnome.org to handle merges of new changes imported from upstream. The problems listed with the svnmerge tool seem to be the same as the ones you run into with CVS: spurious conflicts when working with more than one two branches are involved, not detecting changes that originated in the target branch, etc. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning Gnome Scan Inclusion
Hello, > I am curious to know what the word "flegita" means. Searches using > google and dictionaries in three languages didn't turn up anything which > looked relevant. Good question. :) flegita is an esperanto word that mean "cured". Étienne. -- Verso l'Alto ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning Gnome Scan Inclusion
Hello, > I sure do! please keep up the hard work, this project got me really > excited. Héhé :) I wrote a RoadMap in the Wiki. http://live.gnome.org/GnomeScanning#head-39b656e3f4fce8abe4bf0da2cee994cffa9b90b8 I'm currently packaging gnomescan for debian/ubuntu. Étienne. -- Verso l'Alto ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning Gnome Scan Inclusion
> Do you want gnome scan for 2.18 ? I sure do! please keep up the hard work, this project got me really excited. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On Friday 08 September 2006 08:57, James Henstridge wrote: > The real issue with handling development in parallel branches is > really complexity of merging. This is an area where Subversion > doesn't really buy you much over CVS -- you still need to manually > keep track of what you merged to do a repeated merge. Yet another piece or urban legend. Obviously you have never used the command svnmerge (now part of the svn package). http://www.dellroad.org/svnmerge/index Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On 08/09/06, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote: > Your master plan implies branching early and heavily committing to > both branches for a long time. Reality check: we are still using this > archaic software called C.V.S.! Branching with that software is > incredibly complex. > > Your master plan is blocked by bug #: "migration to > subversion". The real issue with handling development in parallel branches is really complexity of merging. This is an area where Subversion doesn't really buy you much over CVS -- you still need to manually keep track of what you merged to do a repeated merge. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Planning Gnome Scan Inclusion
Hello all ! Since march, i'm designing and developping a Gnome Scan infrastructure. See http://home.gna.org/gnomescan/index and Google "gnome scan" search result in general. I've been sponsored by Google do work on this project this summer. Mentored by Vincent Untz. The project is far from integrated with the Gnome development process. Because of its early stage. I'm waiting for Gnome SVN to drop Gna! hosting (nice service anyway). But, as it become mature, i want to include it officialy in the Gnome Desktop. Here is what gnomescan provide : * libgnomescan : scanner access (based on libsane) * libgnomscanui : widgets using libgnomescan * flegita : a standalone utility for basic scan (ideal for you mother) * flegita-gimp : a Gimp plugin that use an advanced interface Here is what is implemented : * scanner probe * scanner selection * preview * source selection * rotation * single acquisition * save to single file (png, tiff, jpeg and PDF). Here is what is not implemented : * preview zoom * mass acquisition * different x & y resolution * multipage pdf * fixed area selection (a4 , us letter, etc.) * buttons handling And *many* other features. (See http://live.gnome.org/GnomeScanning ). Also, i would like to write plugins for Evolution, Abiword, Inkscape and gthumb. Larry Ewing may write a plugin for f-spot. I'm still working on improving infrastructure design. I've started adding scanner support to hal (generating .fdi). I plan to write a dbus daemon that handle device probe (receiving signals from hal and maybe avahi) and handling buttons. This allow to get ride of the probe dialog and more (buttons handling is quite exciting). But that's a huge work. I plan to implement the dbus service only for 2.20. However, that would be nice to have a kind of preliminary Gnome scan software in 2.18. A kind of RoadMap should be : * 2.18 * fixed area * preview zoom * x & y resolution * mass acquisition * multipage PDF * 2.20 * hal scanner support * dbus service * buttons handling * easy scanner sharing (capplet, avahi publishing) Later version will see OCR, fax, etc. For 2.20, i want to split gnomescan in two parts : gnomescan and flegita. gnomescan will consists of libgnomescan, libgnomescanui, dbus service and capplet. Flegita consists of flegita, flegita-gimp and will receive other plugins. A key point is : does it worth shipping a pure library base app or should we push for a service + library based app for 2.20. Do you want gnome scan for 2.18 ? Thanks for you comments and questions. Étienne. -- Verso l'Alto ! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On Sex, 2006-09-08 at 01:00 -0500, Shaun McCance wrote: > On Thu, 2006-09-07 at 19:32 +0100, Don Scorgie wrote: > > Hi, > > > > On Thu, 2006-09-07 at 11:24 -0700, David Trowbridge wrote: > > > What in particular isn't possible with the 6-month cycle? > > > > For one thing: the documentation gets squeezed. We (the doc team) have, > > basically, 3 month to document all the changes, update all the docs and > > add any new documentation needed. The doc team is currently running at > > skeleton staff and is working right up until the tarball submission > > deadline. This knocks on and means that the doc translations (if > > present) are invariably a release behind. > > > > Don > > /me now waits to see if shaunm will release his top-secret plan for > > world domination... > > Here is my much-anticipated MASTER PLAN: Your master plan implies branching early and heavily committing to both branches for a long time. Reality check: we are still using this archaic software called C.V.S.! Branching with that software is incredibly complex. Your master plan is blocked by bug #: "migration to subversion". -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hi Andrew, Quoting Andrew Cowie <[EMAIL PROTECTED]>: > We regularly have people showing up who are asking us questions about > gtk 2.6 and using a version that is *FOUR* cycles old. We can't support > that as we've long since moved on from there (shit, the people who wrote > that code aren't even involved anymore), with the result that ISV > developers are left out in the cold, and there's no momentum or support > for new developers. Let me see if I can play out this scenario with (say) a 9 month cycle. GNOME 2.2X comes out January 2008. It hits the first distros March 2008, and you get it installed around May. So then you update your bindings to GNOME 2.2X, which are done for GNOME 2.2(X+1), which releases in October 2008. And application developers get that installed sometime around March the year after, when it's released in their distros. So, following your logic, ISDs will be building on GNOME 2.2X APIs in this scheme 18 months after they're done. Isn't this just the same situation again? Cheers, Dave. -- Dave Neary Lyon, France ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
proposal: better ways to print documents
I'd like to suggest two ways to print multiple documents easily, since nowadays it involves opening them one by one which can become burdensome. Please tell me your opinions about these: A. we already can send stuff to a bluetooth device through nautilus-sendto. Wouldn't it be cool to be able to select several documents from nautilus, then sendto → printer? You can find a mockup here: http://img235.imageshack.us/img235/5294/pantallazoenviara1mz9.png B. If the printer dialogue is open, we could just select several icons and drag them to the desired printer's icon. You can see it here: http://img115.imageshack.us/img115/2654/1hw8.gif C. Someone suggested having a printer applet on the panel would be a good idea too, but I'll leave that to you. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Le jeudi 07 septembre 2006, à 19:32, Don Scorgie a écrit : > Hi, > > On Thu, 2006-09-07 at 11:24 -0700, David Trowbridge wrote: > > What in particular isn't possible with the 6-month cycle? > > For one thing: the documentation gets squeezed. We (the doc team) have, > basically, 3 month to document all the changes, update all the docs and > add any new documentation needed. The doc team is currently running at > skeleton staff and is working right up until the tarball submission > deadline. This knocks on and means that the doc translations (if > present) are invariably a release behind. I don't get this. If we move to a longer release cycle, then it will be longer to add more features/changes. And you'll still have 3 months to document even more changes... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
2006/9/8, Rodrigo Moya <[EMAIL PROTECTED]>: > On Thu, 2006-09-07 at 19:51 +0100, Jamie McCracken wrote: > > Hubert Figuiere wrote: > > > Hi, > > > > > > I would like to suggest at one point to try to break with the 6 month > > > release > > > schedule of Gnome to do a "major" release with a certain number of feature > > > that would involve possible infrastructure changes in the platform. > > > > > > There have been a large pimping of project Topaz, and I strongly believe > > > that > > > this is the kind of goal that would need a longer development cycle for a > > > big > > > leap forward towards world domination. > > > > > > Why not thinking for after 2.18 starting on a 12 to 18 month release > > > cycle. We > > > must have a FIRM date (eventually flexible), but more importantly a FIRM > > > features goal (eventually adapted to not become a Death March). > > > > > > What do people think? > > > > > > > I think its worth experimenting with a longer release cycle but I would > > start at 9 months and see if that improves things before considering a > > 12 month or 18 month cycle. > > > > I dont know how topaz will transpire but I feel it should be written in > > a native high level language like D or Vala as its likely to be a > > rewrite of much of the existing code and could be doable in 9 months > > with a more productive language. > > > if we rewrite "much of the existing code", I think we would need much more > than 9 months :-) And if anyone is serious about rewriting said amounts of code in high level languages, I would imagine they are welcome to do so outside the release cycle. In fact, (in my personal opinion) any rewrite has no businnes to be in ANY release until it a) exists as a drop-in replacement (where possible) b) has been moderately tested and approved by the active community c) doesn't mean that half of the now-working stuff suddenly won't work As always, there is little point on carrying on lengthy conversations about fabled rewrites of this and that to the [insert favour here] language. Just go and write it, let's see how it'll work out! -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Thu, 2006-09-07 at 19:51 +0100, Jamie McCracken wrote: > Hubert Figuiere wrote: > > Hi, > > > > I would like to suggest at one point to try to break with the 6 month > > release > > schedule of Gnome to do a "major" release with a certain number of feature > > that would involve possible infrastructure changes in the platform. > > > > There have been a large pimping of project Topaz, and I strongly believe > > that > > this is the kind of goal that would need a longer development cycle for a > > big > > leap forward towards world domination. > > > > Why not thinking for after 2.18 starting on a 12 to 18 month release cycle. > > We > > must have a FIRM date (eventually flexible), but more importantly a FIRM > > features goal (eventually adapted to not become a Death March). > > > > What do people think? > > > > I think its worth experimenting with a longer release cycle but I would > start at 9 months and see if that improves things before considering a > 12 month or 18 month cycle. > > I dont know how topaz will transpire but I feel it should be written in > a native high level language like D or Vala as its likely to be a > rewrite of much of the existing code and could be doable in 9 months > with a more productive language. > if we rewrite "much of the existing code", I think we would need much more than 9 months :-) -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Thu, 2006-09-07 at 13:56 -0400, Pat Suwalski wrote: > Hubert Figuiere wrote: > > I would like to suggest at one point to try to break with the 6 month > > release > > schedule of Gnome to do a "major" release with a certain number of feature > > that would involve possible infrastructure changes in the platform. > > I have been thinking about this as well, just from observing how "shit > hits the fan" near the end of the cycle. > > I'd like to throw out a suggestion that perhaps GNOME should alternate > on a six-month-twelve-month release cycle, regardless of "major release" > or not. It might make planning a little more complicated, but I'm sure > it would be appreciated by developers and users alike. > I think 12 months is too much time. And if we need to do a major release, we can, for instance, branch now for gnome-2-18, do there only minor bugfixes and small feature additions for the upcoming 2-20 and, at the same time, dedicate the 12 months (2-18 + 2-20) to work on HEAD for the major release. That is, there is nothing in the schedule preventing us from working on a major release for 1/1.5 years while at the same time keeping up with the 6-month release cycle. -- Rodrigo Moya <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
