← Back to team overview

screenlets-dev team mailing list archive

Re: Screenlets developpement ?

 

Hi,

With my Debian/Ubuntu hat, it'll be impossible to maintain all the
screenlets from the community in official repository.
Screenlets need a way to easily et safely install individual screenlets.
The PPA is a good idea, except that it's Ubuntu only. A way to install
it with a classic .tar format will be nice also.

For the PPA option, we could create 1 project, to gather bug report,
translations, bzr branch etc ... with 1 PPA. Because adding 1 PPA for
each screenlets could be long :)

A possible option is to use "quickly", and create a template for
screenlets. It will create all necessary stuff and upload to the PPA
automatically.

At least, I think you can begin to summit your modifications to the main
branch, we can sort out the organisation later. The split core -
screenlets is necessary and I think everybody is agreed with this.

Regards,
Julien Lavergne

Le dimanche 07 novembre 2010 à 05:54 +0900, boamaod@xxxxxxxxx a écrit :
> Hello again,
> 
> After just changing a couple of messages with Julien and Rico, I realise 
> that I don't really know what do other people on the project think about 
> the project or about free software in general. It could be that our 
> conceptions about all this are quite different and this could be a 
> reason why we think differently about Screenlets.
> 
> I am really for the freedom and active participation of community and I 
> think Screenlets should be a project in the same spirit. For my mind, 
> Screenlets should be mainly a framework offered for users for running, 
> creating and publishing Screenlets and not so much a ready collection of 
> Screenlets. There are also practical reasons for this: Screenlets' 
> project itself cannot create and maintain a selection of Screenlets good 
> enough and up do date. I think this should be left to community.
> 
> The present way of publishing Screenlets as archived files on the web is 
> rather dirty way of publishing them. It makes publishing of Screenlets 
> episodic (no automatic updates) and not safe (no dependencies checking). 
> It's not a preferred way of installing software on a Debian-based 
> system. Of course a screenlet deloper can decide to publish a Screenlet 
> on a PPA, but this is not encouraged in any way and would be considered 
> rather weird (for example, I think there is now just one (!) Screenlet 
> published in Ubuntu "universe" repositories: monajat-screenlet).
> 
> I think it's time to start encouraging it.
> 
> First of all, we should publish all the Screenlets now in the official 
> package individually on a PPA. And for the next step, we should be 
> agreeing and willing to publish on our PPA any Screenlet that "works". 
> There should be an easy procedure for that. This would make user 
> Screenlets and "official" Screenlets equal by status and this is 
> definitely good for the motivation of the community to develop and 
> publish Screenlets. Only way the official ones would distinguish, is 
> that we also offer a collection of the best of the best available in our 
> PPA as a basic recommendation (which is installed together with the 
> Screenlets core package).
> 
> Installing Screenlets from PPA would add more trust to Screenlets and 
> would make installing third party Screenlets available for either 
> suspicious users (PPA is a legitimate source of installing software, 
> much more legitimate than installing archives randomly downloaded from 
> the WWW) or users without skills needed to search, choose, download and 
> install Screenlets from the WWW (but what every user learns first on 
> Linux system is how to install software from package manager).
> 
> I must admint, that I'm quite eager to make it possible for the 
> community. So I think we have to implement some way of installing 
> individual Screenlets from PPA. So let's ask, what is the best way to do it!
> 
> By now I think I prefer the second of the options I envisaged in my last 
> reply to Julien: To get rid of real Screenlet packs and replace them 
> with metapackages, which bind together individual Screenlets as Debian 
> packages. This would be the most natural way to do it on a Debian-based 
> system and everything would find its solution logically (no problems 
> with separate installation directories for Screenlets, Screenlet packs, 
> core Screenlets etc).
> 
> I stress that this is not just adding a new feature to Screenlets. This 
> is directly addressing the present problem of Screenlets. As you are 
> well aware of, the present problem is that Screenlets have not been 
> updated for more than two years and that the "official" pack of 
> Screenlets is really outdated and not usable for a general public. Can 
> you say that you are completely sure these problems will be solved in 
> the future, if the organization of the project remains the same? 
> Standing before the fact, that there just now was (or still is, to be 
> correct) a two years stall in the project?
> 
> I think these problems would be partly solved by giving users 
> straightforward possibility to commit any Screenlet easily to the PPA, 
> where other users can easily install them. This way it's not only the 
> core developer who holds a responsibility and has means to update an 
> "official" Screenlet, if it's outdated, but it's pushed a bit more on 
> the shoulders of users.
> 
> I'm sure users can do much of it instead of the core developers and core 
> developers will have more time to fix the problems in the core 
> Screenlets package itself. There will be no pressing need to make a big 
> roadmap to next release with the responsibility to fix and guarantee the 
> good condition for every individual Screenlet in the core package. The 
> core developer will just sort out from the metapackage the Screenlets 
> that do not work well, and update only the ones he thinks are really 
> needed to update. It will be much easier and less time-consuming to 
> publish maintenance releases for Screenlets core package and the 
> probability of two year break between releases will be much lower.
> 
> Of course even now, users can fix the core Screenlets, and they do it 
> quite a lot on Gnome-look.org, but these updates are really hard to 
> find, episodic by nature and installing them is wearisome. I hope you 
> see, that publishing these updates in the PPA beside "official" 
> Screenlets would make things completely different. Updates by users 
> would be instantly available to the community, even without the need to 
> go searching for them on Gnome-look.org or some other place.
> 
> This change will also address the the problem which Julien expressed by 
> the words "especially the number is important". It wouldn't be so 
> important anymore to offer a large number of Screenlets as an "official" 
> Screenlets pack, because lot of the updates to individual Screenlets 
> would be done by users (and if users don't fix a particular Screenlet, 
> they probably don't need it so much).
> 
> When I read Rico saying that he has two month "holiday" coming (well, 
> I've done that myself and it will be fun experience for sure, but not 
> really a free time, trust me, Rico!) and we should make a roadmap to 
> "rock-solid 0.2" release without any feature changes, I'm really afraid 
> that will be an overkill, if it is meant to be be done the way it has 
> been done until now (updating all the individual Screenlets and 
> maintaining them). I'm afraid that the community won't get a new 
> Screenlets this way or if they get it, there will be stoppage of the 
> project again, after the "rock-solid 0.2" is reached.
> 
> So my proposal is that we go like this:
> 
> 1) We start applying the patches to the Screenlets core.
> 2) We remove all the individual Screenlets from core.
> 3) We add them to a special source branch for all individual Screenlets.
> 4) We create a special team (or take over some of the existing teams) 
> for updating individual Screenlets (and accept all people willing to be 
> members).
> 5) We create a metapackage to bind couple of really basic and 
> well-functioning Screenlets (by now I propose just Calc, Clock, Flower, 
> Notes, Slideshow and Trash for the beginning, because I have updated and 
> checked these out myself; we can add anything later).
> 4) We create a PPA for Screenlets.
> 6) We publish all individual Screenlets on the PPA as Debian packages.
> 5) We publish the first updated version of new Screenlets core on the 
> PPA (with the metapackage mentioned above in "recommends").
> 
> Notice that this doesn't need any extra features to be added to 
> Screenlets core. It's just a matter of packaging. All individual 
> Screenlets will be still under /usr/share/screenlets and ~/.screenlets 
> so everything is exactly the same. Everything will just work. We don't 
> even need to test it too much either because we are relying on Debian 
> package managment system to do all the hard work.
> 
> Just like that.
> 
> a) The next step would be to update Screenlets documentation about the 
> new way of packaging and announce that any Screenlet is welcome to be 
> included in the individual Screenlets branch, therefore in PPA (and give 
> instructions for that). We offer also a policy for modifications of 
> Screenlets.
> 
> b) Then we should merge individual Screenlets branch with Universal 
> Applets extras, since it contains variety of updated Screenlets easily 
> modifiable to work with standard Screenlets package (I have done this 
> modification already in my Stayin' Alive project).
> 
> c) After that I will add some of my own Screenlets I have 
> created/updated (GoogleCalendar, Slideshow, Twitter, Notes, 
> FreemeteoWeather) in the individual Screenlets branch and PPA. I will 
> publish them also on Gnome-look.org, making a note that these Screenlets 
> as well as all the official Screenlets are also available as Debian 
> packages on the Screenlets PPA (and that individual Screenlets can be 
> added there). I will put the apturl for my packages as well. This will 
> get us some first feedback and users to test out the new PPA style 
> packaging and help to start updating individual Screenlets.
> 
> d) Next, if we think that Screenlets core is "rock-solid" enough, we 
> will publish it as well on Gnome-look.org and GTK-apps.org explicitly as 
> an official new version of Screenlets. This will give a lot of users and 
> lot of feedback for testing, maybe also helping hands to develop Screenlets.
> 
> Somewhere in this point would be to start to merge Screenlets with 
> Universal Applets core, if that's possible.
> 
> Now, I don't know what will be the fate of the individual Screenlets as 
> Debian packages. I mean I'm not sure if they can be added to Ubuntu 
> repositories for the official release (in Natty Narwhal?), but I suppose 
> that the "core" ones can be added without problems, am I right Julien? 
> About rest of them, they will have to be downloaded from PPA. So 
> probably we should create an easy way for users to add this PPA to their 
> systems by just clicking a button in Screenlets Manager.
> 
> I'm not also really sure if there should be different PPAs for 
> Screenlets core and individual Screenlets. If users want to have a 
> "official Ubuntu version" of Screenlets core and still use the variety 
> of individual Screenlet packages from PPA, this would be nice thing to 
> have. But maybe it's too much customisation.
> 
> What we could also do, is to download all the available Screenlets from 
> Gnome-look.org (and Screenlets.org) by means of a download script and 
> create automatically Debian packages from all of them and add these to 
> the PPA. I think this should be just a one-time import, but it's worth 
> thinking about. If you prefer, these could be imported into a separate PPA.
> 
> Please, tell me how do you feel about this plan or propose something 
> else. You see I have code burning in my hands, because I think I have a 
> working and updated version of Screenlets and I want to publish it to 
> the community. I'd really prefer that the Screenlets project won't split 
> into some experimental branch and a main branch.
> 
> Sincerely "etc"
> Guido Tabbernuk





References