Activities packaging

[Morgan Collett]

On Mon, Nov 3, 2008 at 09:31, Marco Pesenti Gritti <mpgritti at gmail.com> wrote:
> On Fri, Oct 31, 2008 at 1:53 PM, Greg Dekoenigsberg <gdk at 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