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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
