A general note about activities packaging... It seem like some of the packages submitted for review uses git snapshots. I would prefer to get releases from upstream for various reasons. I wrote a script to make it trivial to make a source release and I'm figuring out the best way to solicit activity authors to get in the habit.
Marco
On Fri, 31 Oct 2008, Marco Pesenti Gritti wrote:
A general note about activities packaging... It seem like some of the packages submitted for review uses git snapshots. I would prefer to get releases from upstream for various reasons. I wrote a script to make it trivial to make a source release and I'm figuring out the best way to solicit activity authors to get in the habit.
If the script is trivial, perhaps it's something we put on the shoulders of the packagers, rather than the maintainers?
I ran into this when I tried to package Pippy. I think the problem is that Activities are perhaps a bit lighter weight than many more "formal" applications, and thus the notion of a "release" is a bit less... clear.
This may bite us for a number of reasons. There's a whole art around release engineering, even in its most minimal form, that you sort of have to "buy into".
Ideally, we could just say "create release tarballs" and make it so by fiat... but I don't yet have a feel for how committed activity developers are in general.
--g
On Fri, Oct 31, 2008 at 1:53 PM, Greg Dekoenigsberg gdk@redhat.com wrote:
On Fri, 31 Oct 2008, Marco Pesenti Gritti wrote:
A general note about activities packaging... It seem like some of the packages submitted for review uses git snapshots. I would prefer to get releases from upstream for various reasons. I wrote a script to make it trivial to make a source release and I'm figuring out the best way to solicit activity authors to get in the habit.
If the script is trivial, perhaps it's something we put on the shoulders of the packagers, rather than the maintainers?
Perhaps the packagers could collaborate with the maintainers on it? Some level of collaboration is necessary to ensure that a certain release means the same things on all the distributions, and that we do package code that is ready to be. Also the release script does things like uploading to the official source repo and sending out announcement mail, which obviously needs to be agreed with the maintainer.
Without the above conditions, it's probably better to just release from git, which is better than nothing for packages on which we can't get maintainers collaboration.
Marco
On Mon, Nov 3, 2008 at 09:31, Marco Pesenti Gritti mpgritti@gmail.com wrote:
On Fri, Oct 31, 2008 at 1:53 PM, Greg Dekoenigsberg gdk@redhat.com wrote:
On Fri, 31 Oct 2008, Marco Pesenti Gritti wrote:
A general note about activities packaging... It seem like some of the packages submitted for review uses git snapshots. I would prefer to get releases from upstream for various reasons. I wrote a script to make it trivial to make a source release and I'm figuring out the best way to solicit activity authors to get in the habit.
If the script is trivial, perhaps it's something we put on the shoulders of the packagers, rather than the maintainers?
Perhaps the packagers could collaborate with the maintainers on it? Some level of collaboration is necessary to ensure that a certain release means the same things on all the distributions, and that we do package code that is ready to be. Also the release script does things like uploading to the official source repo and sending out announcement mail, which obviously needs to be agreed with the maintainer.
Without the above conditions, it's probably better to just release from git, which is better than nothing for packages on which we can't get maintainers collaboration.
Getting releases done in a standard process helps all the distro packagers, as we know where to go to get the latest, or a particular, version of the source tarball or the .xo. Perhaps we could identify a set of packages which we want to maintain well, and either encourage the author to follow the release process or do the extra steps ourselves, for the benefit of Fedora, Debian, Ubuntu etc.
Here are my recommendations for activity authors/maintainers, especially those not already following the Frucrose process:
* Release early, release often.
Don't wait for some level of completeness - if it runs, ship it! Others will be able to contribute, or comment, if they can see it in action, no matter how early the project is. Don't do a release for every commit, but every time there is a significant improvement, get it out there.
If pootle is adding translations to your git repository, do periodic releases to bring in the new translations.
* Use a revision control system.
Git is not easy to learn, but once it's up and running you only use three or four commands on a regular basis. Getting your code versioned means others can see the progress, and can contribute patches by branching into their own repos and committing, ensuring that code doesn't get lost. It also helps when a maintainer wants to hand over the project to someone else, or when others want to get involved. If you don't use git, use something at least.
Commit your changes in discrete commits that include only related changes. Don't reformat the source code and add new features in the same commit. Rather do it in separate commits, so that others can see what changed for the features or fixes. Try to not include more than one feature or fix in a single commit. If you need help with git, ask on IRC or a mailing list.
* If possible, don't publish the actual .xo files as uploads to the OLPC (or any other) wiki.
It puts a big drain on the wiki when lots of people download .xo files from the wiki. They should preferably be linked from the wiki but actually hosted on a conventional web server. OLPC provides hosting - http://wiki.laptop.org/go/Project_hosting. If you applied and didn't hear back, ask again. You can use the shell account on dev.laptop.org to host the .xo files - I put mine in my public_html/bundles so they show up at http://dev.laptop.org/~morgan/bundles.
Regards Morgan
-
Greg DeKoenigsberg -
Marco Pesenti Gritti -
Morgan Collett