On 05/25/2015 07:10 AM, Anto wrote:
>
> Thanks Jaret,
>
> If I understood your steps correctly, that requires to have copies of
> the upstream sources on the local development platform. One example is
> your eudev project (https://git.devuan.org/jaretcantu/eudev). :) I am
> sorry to use it as example, but I am sure you know about it much
> better than anyone else.
>
Any other project that was cloned from anonscm.debian.org/cgit would
do. Here's another one I cloned from there which makes far fewer
radical changes:
https://git.devuan.org/jaretcantu/accountsservice

> This is actually one of the parts that I really cannot get my head
> around that. If the source packages were already being properly
> maintained on good development platforms, I don't see the point to
> have their copy on the local development platform as that would be a
> waste of disk space and double the development efforts in maintaining
> them. That would only be necessary if the upstream sources were being
> provided in tarballs, instead of for instance on git platform which
> their historical changes are being recorded.
I guess the problem there is "If the source packages were already
properly maintained." They would also have to be maintained in git,
maintained by the Debian package maintainers, *and* they would have the
bloat of the full git development history (if you want to talk about
wasted space).

I don't know if this is more historical or just to unclutter the git
history of the packaging branch from irrelevant changed. Dropping in a
new release tarball every so often is no more difficult than re-merging
with upstream every release.

Build errors kept springing up as I added more and more project until I
started using the exact Debian workflow, at which point the new issues
stopped, so this is what I stuck with.

> So in the case of the source packages that are located on public
> development platform like github, what I thought needs to be done on
> for instance Devuan's gitlab is to maintain only the build package
> script like what I just did. :)
As long as the history never gets blown away or rewritten. Which it can.
Because it is git.
I think this is the reason people choose to maintain their own
independent history; you can trust yourself a lot more than other people.

> I assume that you are referring to the commit title of "Update for
> gentoo eudev master branch up to commits on May 4, 2015". If so, yes I
> was confused what to put in there as it is a master branch so no
> release tag. I wanted to put the latest commit on the master branch
> but it looks too long for a commit title, e.g.
> https://github.com/gentoo/eudev/commit/8387ce96ffd04ce048368480a269cbf5166394db
> or commit 8387ce96ffd04ce048368480a269cbf5166394db. So I decided to
> put the date there instead. Do you or anybody have any suggestions to
> use "more standardise" information?
git tag

Or on github, click the "branch: master" menu, select the Tags tab, and
there are your tags.



One final nitpick that I didn't even notice before: if you are forking a
project, you should click the Fork button on said project. This allows
someone to trace where you project's source came from in the Network
view and also notifies anyone looking at the original source tree that
someone is currently doing separate development on on that project. It
also gives a nice divergence flow chart.

The commit history is there, which is great for pure git, but on a
project-y interface like GitLab or github, you should probably use the
project-y buttons.



~jaret