On 11/28/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> On Tue, 28 Nov 2006 19:29:17 +0100, Hisham Muhammad
> > Scripts to simplify svn handling will certainly be done. But we have
> > to think things over very well on how to handle this. We want to make
> > its use the least bureaucratic as possible, while still retaining a
> > good history of where changes in recipes come from (making good use of
> > 'svn copy'). For instance, I think we'll need a script to get a recipe
> > tarball sent by a user, svncopy the latest version of the program from
> > the trunk and then apply the differences of the user's recipe over the
> > copied version, so that the file in the server retains the full
> > history across versions instead of looking like a fresh Recipe file.
> >
> Agreed. The code above was just an draft. But I still think this can be
> built into the current tools instead of making (yet) another script. So

Sure. But some new scripts will probably show up for new parts of the workflow.

> what if NewVersion checked out the old version of the recipe and made 'svn
> cp' of that instead of doing it the way it's done now. Another variant is
> to make the user supplied tarball of the patch, like
> Foo--1.2--patch.tar.bz2, which is applied to a copy of the current version.
>
> I thought that with the recipes in the svn more people should get write
> access

Yes, that's the plan.

> and Lucas (or who it might be) just review the trunk and create a
> revision if it looks ok.

As people "take ownership" of recipes, I don't even think revisions
will have to go through a single global reviewer anymore.

> Therefore, going the detour around the tarball
> makes too much work as it's many submissions.

I just don't want to require svn for one-off contributors. For those,
the current workflow (make a recipe under LocalRecipes, pack a tarball
and submit by email) works fine.

-- Hisham
_______________________________________________
gobolinux-devel mailing list
[email protected]
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Reply via email to