On 25/05/15 14:09, Jaret Cantu wrote:
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.
Thanks for your explanation, Jaret.
Yes. I get the point that it is better to maintain the sources on the
local development platform, as we have better control over the sources.
That is actually more and more applicable these days, in the case of the
"contaminated packages" (which is quite a lot recently and will be more
in the future). So that we can cherry-pick only the un-contaminated and
necessary changes.
In the case of eudev, I believe I can still trust the people who
maintain it so far, though I needed to add a patch to remove the
"contaminated" changes. I think it is still reasonably maintainable
without having the copy of the source. But that is because I have only
been observing it in the last few days. So let's see about that in
longer term.
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.
As I previously mentioned, there is no release tag on the master branch.
The latest release tag on eudev, i.e. v3.0, that you are referring is
146 commits behind the master branch. I decided not to include the
debian build package script for release tag v3.0 as it has some issues
that I experienced myself. All the issues that I experienced have been
fixed by the commits after release tag v3.0.
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.
Yes. I did fork your eudev project on gitlab about 3 days ago. But I
noticed that I would have to pull and push a lot of commits as the
source in your eudev project is 491 commits behind the gentoo/eudev
master branch. So I dropped it as I will need more time to learn a lot
more to be able to properly do that. So I decided to fork only the
debian directory from your eudev project and only up to a certain commit.
~jaret
Cheers,
Anto
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
