[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upstream source handling



Ben, thanks for the comments.

On Sat, Nov 07, 2015 at 01:48:51PM +0000, Ben Hutchings wrote:
> On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote:
> > Main principles:
> So genorig.py would be replaced with 'git archive'?

Yes.

> > Workflow:
> > - New upstream version
> >   - Rebase old tag on top of new upstream, tag it with the new version
> There are no tags in the repository you created.  Can you add one as an
> example?

Done.

> Do you think we would tag when updating to a new upstream version, or
> only when making the first upload with a new orig tarball (allowing for
> further DFSG changes before uploading)?

I think we have to tag while updating.  We would need to rebase the
already published branches, if we change the orig later.  Also it is
impossible to build a source package without the tag.

> >   - Rebase old main featureset branch on top of new orig tag as new
> >     branch
> >   - Rebase old other featureset branches on top of new main featureset
> >     branch or replace with new base and create new branch
> >   - Record new top commits and update changelog in main repo
> That's a lot of rebasing, though not so different from what we do now
> to refresh the patch series.  Presumably we would add a script to
> support this and ensure it is all done properly?

Sure, thats support infrastructure.

> The submodules are checked out with detached heads by default.  Is your
> intent that we would override this?

Do you know if we can change it?

> I tried this:
>     $ cd source/orig

source/orig is supposed to go away.  At least that was my plan.

> Is it possible to combine those push commands?  Is this something else
> we would need to script?

It is possible to change the way push works via the config, you can
specify what is going to be pushed.

> > - Cherry pick patch
> >   - (Make sure the submodules are on the correct branch, otherwise it
> >     will be hard to push changes or they will go to incorrect locations)
> >   - Cherry pick patch
> >   - Merge changes into all derived featuresets, if any
> Rather than rebasing?

Rebasing published branches is no nice thing to do.

> What I don't like:
> 3. Pushing is more complicated

git push can push all submodules as well, but I don't see a config
option for it.

> 4. Cherry-picking is more complicated

Yeah.  That warrants a script.

> 6. It's not possible to see the history of one of our patches

Which history do you mean?

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1


Reply to: