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