Re: [gentoo-user] Re: status of dev-java/icedtea

[Rich Freeman]

On Sat, Jul 2, 2016 at 2:26 PM, James <wireless@×××××××××××.com> wrote:
>
> That's not my reality. I volunteered to take over (4) cluster packages
> from the soon-to-retire dev, jsbronder, on gentoo-dev. It was agreed to.
> In another thread, I basically stated that I am not compatible with irc, so
> some devs said oh, we now have a mail_list for proxy maint. Cool, right?
> Well, I've subscribe to the list several times, tried to post directly
> to the ML and via gmane::
>
> ttp://news.gmane.org/gmane.linux.gentoo.proxy-maint
>
> to no avail.

Can you elaborate?  You posted and nobody replied?  You were never
able to post?  It isn't really clear what the issue is here...

>
> I was told to change the metadata.xml on the packages I wanted to claim,
> but I cannot find an example of how a ordinary user can do this. If it
> is a 'pull request' via github, somebody needs to document that somewhere as
> it is the first step and a critical step.
>

You'd need somebody else to commit it for you.  A pull request would
be a good way to go about it.

> There needs to be a way to ask questions, via a MailList on for proxy folks
> so those questions and answer can be coallesced into a FAQ and eventually be
> use to create formal gentoo wiki docs. The routine actions of a proxy-dev
> (let's say the most common 20-40) things you need to know and do, needs to
> be documented (in the gentoo wiki) including a cookbook on github.

That would be the mailing list you just mentioned.

And this:
https://wiki.gentoo.org/wiki/Gentoo_Github

Of course, it could probably be improved.

>
> So a new overlay that I run, should be on github?  I need help with github,
> it's a blocker of a lot of my gentoo work.
>

Overlays can be hosted just about anywhere.  But, github is a good
place if you don't have something better, since it combines
distribution and version control.  You could just stick a directory on
a webserver anywhere and copy your /usr/local/portage over to it and
you'd be 98% of the way there.

>
> Obviously we agree on leaving old codes around. If they are to be removed
> from the tree, a mechanism for invididuals to resurrect them needs to be
> complete, *FIRST*, imho.
>

We can't just leave broken packages in the active tree until somebody
feels like improving documentation.

The situation would hardly be improved if 30% of the time when
somebody finds a package in the repo they type "emerge pkgname" and it
gives a build error.

If it isn't broken, it shouldn't be removed at all.  If it is broken,
it simply has to be removed.

>
> What the github replacement for the attic, and where do I find docs on how
> to use it. github is a 'pita' for this old C hack..... Perhaps stop the tree
> cleaning until there is a documented replacement (github centric)
> for the attic?
>

It is a bit of a pita with git, unfortunately.  You need to search the
history to find deleted files (there is no record in the present
commit of anything that doesn't exist in the present, so git has to
basically go back and check every past commit until it finds a file
you search for by name).  You need to clone the repo and then use
something like this:
https://stackoverflow.com/questions/7203515/git-how-to-search-for-a-deleted-file-in-the-project-commit-history

If somebody wanted to actually list all the deleted files in a
directory (which in CVS you'd do just by looking at the contents of
the Attic directory), you'd need to systematically diff every single
tree in git against its predecessor in history and make a note of
anytime a file disappears (that isn't quite as bad as it seems as you
can tell whether anything in a directory's children have changed just
by comparing the parents, so it isn't like you need to descend every
subdirectory in every commit).  I have a script that basically does
that using a map/reduce approach (it finds every unique version of
every file in the history by comparing every commit against its
predecessor).

Don't get me wrong - I get that git is a bit hard to get into.  It is
one of those things that you'll struggle with until you grok it.  I
will tell you that it is worth groking though.  Oh, and the standard
git command-line program has a horrible interface (in terms of
parameters, commands, etc).  It is inconsistent and confusing.
SVN/CVS were much simpler to understand in comparison, as they didn't
require some kind of paradigm shift to appreciate.

I can't say I have a handy reference to get started with.  This one
seems to start out good at least:
https://www.sbf5.com/~cduan/technical/git/

I will agree with his opening premise:
The conclusion I draw from this is that you can only really use Git if
you understand how Git works. Merely memorizing which commands you
should run at what times will work in the short run, but it’s only a
matter of time before you get stuck or, worse, break something.

Git is basically a really great data model with a command line
interface that Linus whipped out in 20min so that he could get back to
the kernel, with a bunch of commands that he basically tossed together
anytime something annoyed him (git-am, anyone?).

-- 
Rich