Re: [gentoo-dev] ChangeLog - Infra Response

[Ulrich Mueller]

> On Mon, 2 Nov 2015, Robin H Johnson wrote:

> 1. Control of the OUTPUT filename for the generated changelog
> - the from-git generated changelog will go to 'ChangeLog.git'

> [...]

> Without #1, we have to rename ALL of the old changelogs, otherwise
> they will be overwritten by the new ones from Git history.

What would be the problem with renaming? IMHO it would be nicer to
keep the ChangeLog name for the autogenerated files and rename the
ones from CVS. We already have files renamed to ChangeLog- when
they became to large, so we could just use ChangeLog-2015 to stay
within that scheme.

Ulrich


pgpeIWzEGeDCQ.pgp
Description: PGP signature

Re: [gentoo-dev] Re: ChangeLog

[Patrick Lauer]

On 11/02/2015 03:04 AM, Michael Orlitzky wrote:
> On 11/01/2015 08:22 PM, Duncan wrote:
>> Personally, I'd love the primary sync method to be git, and the primary 
>> change logs conveyed via native git log methods, but in ordered to do 
>> that, all those rsync mirrors need to switch to git mirrors.
>>
> I wonder what would happen if we just... dropped a full clone of
> gentoo.git onto the rsync mirrors?
>
>
You find out how many users have limited bandwidth (again)

Why on earth would you do the most wasteful hybrid strategy when people
are in general trying to optimize for efficiency?

And why am I still sober?

Re: [gentoo-dev] Re: ChangeLog

[Patrick Lauer]

On 11/02/2015 02:56 AM, Rich Freeman wrote:
> On Sun, Nov 1, 2015 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>  I know if I were still on rsync (or webrsync), I'd be raising hell about 
>> the lack of
>> changelogs well before now
> Perhaps rather than raising hell you'd do better to raise money to
> hire an infra team to fix the bug or something.
Hire?
I'm still willing to fix things, if I were given access. And I would
presume that I'm not the only one.

But since I don't have access, and can only affect things by motivating
or upsetting people, we have a large mail thread that is mostly about
smug people being smug. Which confuses me since it's not Tuesday, but I
digress ...
>
> I get the frustration, but we only have a few people who have the
> necessary access to fix the problem.
So fix that.
>   Infra is also a difficult
> project to deal with in general because it is fairly closed due to the
> implications of having random people messing with it.  I don't really
> see anybody stepping up to try to change anything fundamental about it
> either.  This isn't the sort of thing that will get better if the
> council votes on something.
>
Yes, voting is not going to fix anything directly. So I didn't even
suggest it.

But one of the conditions for tolerating the git migration was that we
have no regressions.
Now it's about 3 months later and *basic* functionality is still
"Oopsiedaisy, I must have missed that"

Which is confusing me because ... uhm... didn't anyone ... test things?
Document? How can something be deployed that is obviously missing
features like this?

(And as a consequence, why doesn't it then get fixed in a reasonable time?)


But at least now we get some good information what is broken how, and
maybe someone can fix it. And then I won't have to be the stone in
people's shoe anymore ;)

Re: [gentoo-dev] ChangeLog - Infra Response

[Michał Górny]

Dnia 2 listopada 2015 06:50:39 CET, "Robin H. Johnson"  
napisał(a):
>I'm replying to the top level of the thread, because I've been on
>offline vacation recharging myself for a week, and this thread seems to
>have degenerated into ways to avoid the issue, rather than focusing
>with
>what's actually wrong.
>
>rsync-as-a-way-to-get-the-tree is NOT being deprecated, it has very
>valid use cases, and places where git is not suited.
>
>I asked zmedico & dol-sen for TWO critical changes to egencache's
>--update-changelogs code.
>
>1. Control of the OUTPUT filename for the generated changelog
>- the from-git generated changelog will go to 'ChangeLog.git'
>2. Control for the order ENTRY for the generated changelog 
>- changing to OLDEST-first, with appending the new data at the end
>- this massively improves rsync performance.
>
>dol-sen said he was busy with the repoman rewrite, and didn't want to
>introduce the change at the time, so this has been deferred for the
>moment.
>
>Without #1, we have to rename ALL of the old changelogs, otherwise they
>will be overwritten by the new ones from Git history.
>
>I probably should have created a bug for both of these, because I don't
>know if they got tracked accurately since I asked for them in August,
>and I certainly don't see the code being updated in the repoman or
>master branches of the portage repo (it also still generates a $Header$
>entry, which does have an open bug as we.

You should have indeed. Both seem trivial and I'd have done them a long time 
ago if anybody bothered telling me about it.

>
>Since dol-sen and zmedico are so busy as well, somebody from this
>thread
>with time to complain, please implement & test these changes!
>It's NOT as trivial as dropping a variable into the place where it
>opens
>the file, because there is other code later that also hardcodes the
>filename.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Re: ChangeLog

[Dale]

Rich Freeman wrote:
> On Sun, Nov 1, 2015 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>  I know if I were still on rsync (or webrsync), I'd be raising hell about 
>> the lack of
>> changelogs well before now
> Perhaps rather than raising hell you'd do better to raise money to
> hire an infra team to fix the bug or something.
>
> I get the frustration, but we only have a few people who have the
> necessary access to fix the problem.  Infra is also a difficult
> project to deal with in general because it is fairly closed due to the
> implications of having random people messing with it.  I don't really
> see anybody stepping up to try to change anything fundamental about it
> either.  This isn't the sort of thing that will get better if the
> council votes on something.
>


Then perhaps all this should have been worked out BEFORE switching to
github? 

As a user, I would look at the change logs pretty regular, more than the
ebuilds to be honest.  Now, there is none.  If a package changes, I have
no clue why it changed unless I go dig that information out somewhere
and that somewhere doesn't seem to be in one place.  When I tried to dig
some info out a while back, I found some on github thingy and then some
more on gentoo.org itself.  I'm still not sure what change lead to what
because there is no real order of events that I could see.  This was
shortly after the change.  After that, screw it. 

I don't mind change but it seem this one wasn't really ready to be done
yet although most made it sound like it was.  I been using Gentoo since
2003, the 1.4 days, and even I can't figure out where to find
information easily and I have a stable DSL connection.  I feel real
sorry for people who don't have one.  I might add, I had a really
limited dial-up connection when I first started using Gentoo so I know
how it is to be in that situation.  I haven't forgot those days. 

Going back to my hole for the simple reason, it's screwed up and no one
seems to think it worth fixing.  I noticed that as soon as I saw the you
need to figure out a way to fix it yourself comment.  One thing about
being around so long, when you see that comment, you may as well kiss it
good bye.  That's code for we aren't going to fix it, you figure out a
way for yourself.  It's rare that anything gets fixed after that. 

Dale

:-)  :-) 

Re: [gentoo-dev] ChangeLog - Infra Response

[Robin H. Johnson]

I'm replying to the top level of the thread, because I've been on
offline vacation recharging myself for a week, and this thread seems to
have degenerated into ways to avoid the issue, rather than focusing with
what's actually wrong.

rsync-as-a-way-to-get-the-tree is NOT being deprecated, it has very
valid use cases, and places where git is not suited.

I asked zmedico & dol-sen for TWO critical changes to egencache's
--update-changelogs code.

1. Control of the OUTPUT filename for the generated changelog
- the from-git generated changelog will go to 'ChangeLog.git'
2. Control for the order ENTRY for the generated changelog 
- changing to OLDEST-first, with appending the new data at the end
- this massively improves rsync performance.

dol-sen said he was busy with the repoman rewrite, and didn't want to
introduce the change at the time, so this has been deferred for the
moment.

Without #1, we have to rename ALL of the old changelogs, otherwise they
will be overwritten by the new ones from Git history.

I probably should have created a bug for both of these, because I don't
know if they got tracked accurately since I asked for them in August,
and I certainly don't see the code being updated in the repoman or
master branches of the portage repo (it also still generates a $Header$
entry, which does have an open bug as well).

Since dol-sen and zmedico are so busy as well, somebody from this thread
with time to complain, please implement & test these changes!
It's NOT as trivial as dropping a variable into the place where it opens
the file, because there is other code later that also hardcodes the
filename.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: ChangeLog

[Michael Orlitzky]

On 11/01/2015 08:22 PM, Duncan wrote:
> 
> Personally, I'd love the primary sync method to be git, and the primary 
> change logs conveyed via native git log methods, but in ordered to do 
> that, all those rsync mirrors need to switch to git mirrors.
> 

I wonder what would happen if we just... dropped a full clone of
gentoo.git onto the rsync mirrors?

Re: [gentoo-dev] Re: ChangeLog

[Rich Freeman]

On Sun, Nov 1, 2015 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>  I know if I were still on rsync (or webrsync), I'd be raising hell about the 
> lack of
> changelogs well before now

Perhaps rather than raising hell you'd do better to raise money to
hire an infra team to fix the bug or something.

I get the frustration, but we only have a few people who have the
necessary access to fix the problem.  Infra is also a difficult
project to deal with in general because it is fairly closed due to the
implications of having random people messing with it.  I don't really
see anybody stepping up to try to change anything fundamental about it
either.  This isn't the sort of thing that will get better if the
council votes on something.

-- 
Rich

[gentoo-dev] Re: ChangeLog

[Duncan]

Patrick Lauer posted on Sun, 01 Nov 2015 13:16:31 +0100 as excerpted:

> I'm getting mildly very irritated with the lack of easily accessible
> ChangeLogs for our packages.
> 
> Apparently updating them stopped some time in August, so now there are
> some outdated ChangeLogs that don't really serve any purpose, and the
> easiest way for users to figure out why something changed is to yell at
> the clumsy gitweb.g.o interface. So instead of grep we now need lots of
> patience.
> 
> This does not look reasonable to me.
> 
> Can we please either properly remove ChangeLogs and tell people to not
> be curious about changes, or make them useful again?

++

I got irritated with that within a week of the git switch, and pretty 
quickly switched to the github mirror with pregenerated metadata.

That gives me the git log, which is perfectly fine by me. =:^)

But, that's not at all suitable for the general user.

For one thing, while one would hope that github should have no problem 
with the traffic, there's little question that recommending that as the 
general gentoo-wide solution runs headlong into the social-contract issue 
currently being debated on the NFP list.  While simply taking commits via 
github from users who want to use it for that is one thing (and fine by 
me, I'm not /that/ extreme, as long as the proprietary method doesn't 
come to be favored), having pretty much the entire userbase syncing from 
it would be pretty hard *not* to call a "dependency", and thus a 
violation of the contract.

Which means the generally recommended sync method really needs to stay on 
gentoo infrastructure, or at least with direct gentoo volunteer hosts, 
tho some may be hosting on proprietary platforms.


Personally, I'd love the primary sync method to be git, and the primary 
change logs conveyed via native git log methods, but in ordered to do 
that, all those rsync mirrors need to switch to git mirrors.

Meanwhile, as pointed out elsewhere in the thread, git syncing simply 
won't work under some circumstances, as it's all or nothing, and for some 
people the connection simply isn't stable enough to get all, so it ends 
up being nothing.  

But as long as webrsync continues to work, and assuming it can be 
incrementally fetched/resumed, that should be a sufficient solution for 
them, so again, rsync isn't really necessary.  And for those users, if 
they do need to check the changelog, the packages.gentoo.org method, 
following the link to the git log if necessary, should be fine.


But clearly, something needs to change.  Either the changelogs need to be 
fixed to be generated again, or the old ones need removed, with people 
not using git pointed at packages.gentoo.org as mentioned.  If the 
general rsync mirrors are eventually switched to git, with webrsync 
remaining for those who can't do git, great, but meanwhile, I know if I 
were still on rsync (or webrsync), I'd be raising hell about the lack of 
changelogs well before now, and the github mirror I'm actually using 
clearly isn't suited as general gentoo user solution because it /would/ 
then be a gentoo dependency and thus a violation of the social contract, 
so I'm definitely with Patrick on this one.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Gentoo-hosted code review

[Duncan]

Michał Górny posted on Sun, 01 Nov 2015 19:34:06 +0100 as excerpted:

> On Mon, 2 Nov 2015 04:44:39 +1100 Michael Palimaka
>  wrote:
> 
>> There's been a lot of discussion about relying on GitHub for pull
>> requests and code review and such, so I have set up a Phabricator
>> instance against gentoo.git to see how a free alternative might work.
>> 
>> Here's a few examples of how things could work:
>> 
>> General post-commit review:
>> http://phabricator.astralcloak.net/
rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca
>> 
>> Tracking commits with issues that need attention:
>> http://phabricator.astralcloak.net/audit/query/open/
>> 
>> Pre-commit review: http://phabricator.astralcloak.net/D1
>> 
>> Phabricator also has all sorts of fancy (optional) features that could
>> be useful for collaborative development (see http://phabricator.org/
>> for more info).
>> 
>> What do you think?
> 
> At a first glance -- terribly unreadable, wtf is all that tiny stuff
> thrown at me all at once? But I guess we can get used to it, or get some
> kind of sane theme. Tiny, gray text on a little brighter gray background
> with some more shades of gray-cyan around doesn't help readability at
> all.

What browser were you using?  Seems reasonable here on firefox, and I 
often enough have problems with web pages that I normally run privoxy 
primarily as a color filter (as well as font size adjuster), switching 
the normal dark text on a glaring white background to light text on a 
dark or black background, without forcing all pages to the same color 
scheme as the normal user-side accessibility style-sheet would do.

I tried both with my privoxy filters active, getting the expected light 
text on dark background (with darker red and darker green where they'd 
normally be light, and black as the default), and with privoxy bypassed, 
which gave me a white background with black or near-black text, except 
for the diffs, etc, which had the expected light red/green backgrounds, 
and links, standard browser link color (here set to cyan unvisited, 
yellow visited), I believe.

And at normal 100% zoom, firefox displayed ordinary sized readable text, 
too, no zooming in/out necessary.

So I'd guess it was either your browser, or the theme was already 
switched (possible I suppose, tho I don't see a post here indicating 
that).

> What's the deal with 'rGENTOO56bd759df1d0'? Can't it be made to use
> normal commit hashes, or at least put some separator in that? I know
> enlightenment people like this kind of stuff but it's neither friendly,
> not readable. And it's going to make copy-paste harder.

++.  That's inconvenient, to say the least.

> Second thought, it's slow. I mean, I open a directory and wait a few
> seconds for detailed information to appear, with my CPU getting hot for
> no good reason. I can only guess how hot the server gets in the
> meantime...

While waiting for the detail did take a bit, I didn't notice my CPU doing 
anything unusual and rendering seemed speedy enough once the detail came 
down, even tho I had been primed by your post to look for it.  Again, 
that was with or without privoxy doing its own parsing and filtering as 
well.  Again, the CPU thing could well be browser specific.

But while for just browsing the delay didn't seem extraordinarily long 
for being served from an Internet server obviously doing some dynamic 
calculation and page generation, actually working with it, I agree, 
waiting for the detail to show up could get old rather fast.

While my home system's reasonably powered for a gentoo build system (I'd 
say nothing special mid-grade given it's a build machine, AMD bulldozer-1-
based fx6100, 6-core, slightly overclocked to 3.6 GHz, 16 gig RAM), the 
systems I use at work are slow enough I press a button and find myself 
wondering if it's just slow to respond, or if it didn't register and I 
need to press it again, and while one does get used to pressing a button 
and waiting... it's definitely nice to be back on my own faster system 
again.  So I know what it's like trying to work with slow responding 
systems for hours at a time, and yes, while one does get used to it, it 
certainly does get old, and I can well imagine this would as well.

But as I've not used any other review systems and just browsed this setup 
a bit, I've nothing to go on in terms of comparison.

(No real opinion on the rest.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-11-01 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2015-11-01 23:59 UTC.

Removals:
dev-java/commons-modeler 20151026-23:13 chewi 0c6d5d1
dev-java/commons-transaction 20151026-23:27 chewi b7e36ec
dev-java/hibernate   20151026-23:23 chewi ada875a
dev-java/hibernate-annotations   20151026-23:23 chewi 46d1933
dev-java/jax-rpc 20151026-23:13 chewi f97b65f
dev-java/mx4j20151026-23:14 chewi 8a9cf23
dev-java/mx4j-core   20151026-23:15 chewi 2bb4f77
dev-java/mx4j-tools  20151026-23:16 chewi 8c6f817
dev-java/proxool 20151026-23:26 chewi ca9f85a
dev-libs/libjwc_c20151026-07:29 jlec  7d62034
dev-libs/libjwc_f20151026-07:29 jlec  7d62034
net-firewall/shorewall6  20151027-03:01 idella4   ee2e65a
net-firewall/shorewall6-lite 20151027-03:01 idella4   ee2e65a
net-firewall/shorewall-core  20151027-03:01 idella4   ee2e65a
net-firewall/shorewall-init  20151027-03:01 idella4   ee2e65a
net-firewall/shorewall-lite  20151027-03:01 idella4   ee2e65a
sci-chemistry/arp-warp-bin   20151026-07:29 jlec  7d62034
sci-chemistry/balbes 20151026-07:29 jlec  7d62034
sci-chemistry/ccp4-apps  20151026-07:29 jlec  7d62034
sci-chemistry/ccp4i  20151026-07:29 jlec  7d62034
sci-chemistry/imosflm20151026-07:29 jlec  7d62034
sci-chemistry/makecif20151026-07:29 jlec  7d62034
sci-chemistry/molrep 20151026-07:29 jlec  7d62034
sci-chemistry/mosflm 20151026-07:29 jlec  7d62034
sci-chemistry/mrbump 20151026-07:29 jlec  7d62034
sci-chemistry/oasis  20151026-07:29 jlec  7d62034
sci-chemistry/pdb-extract20151026-07:29 jlec  7d62034
sci-chemistry/phaser 20151026-07:29 jlec  7d62034
sci-chemistry/pointless  20151026-07:29 jlec  7d62034
sci-chemistry/refmac 20151026-07:29 jlec  7d62034
sci-chemistry/scala  20151026-07:29 jlec  7d62034
sci-chemistry/sfcheck20151026-07:29 jlec  7d62034
sci-chemistry/solve-resolve-bin  20151026-07:29 jlec  7d62034
sci-chemistry/xdsi   20151026-07:29 jlec  7d62034
sci-chemistry/xia2   20151026-07:29 jlec  7d62034
sci-libs/balbes-db   20151026-07:29 jlec  7d62034
sci-libs/ccp4-libs   20151026-07:29 jlec  7d62034
www-servers/axis 20151026-23:25 chewi 1eda279
x11-libs/libxdl_view 20151026-07:29 jlec  7d62034

Additions:
app-shells/z 20151029-00:30 aidecoe   6b353f9
dev-java/jssc20151031-09:00 monsieurp e35c76a
dev-java/myfaces-api 20151030-22:22 monsieurp d908894
dev-java/myfaces-builder-annotations 20151030-22:23 monsieurp e68d738
dev-libs/libmaxminddb20151031-05:24 jer   8862d97
dev-python/cassandra-driver  20151028-00:14 stasibear bc77029
dev-python/dj-database-url   20151028-09:51 jlec  8bc9a2e
dev-python/pytest-raisesregexp   20151101-01:03 alunduil  188f6a2
dev-python/pytidylib 20151027-08:53 jlec  3c3dbbf
dev-python/pyuv  20151027-13:31 hasufell  f89c61f
dev-python/versioneer20151030-14:14 jlec  6898881
dev-ruby/gherkin320151030-05:56 graaff5c9baca
media-libs/kvazaar   20151030-12:39 aballier  793cfe5
media-libs/zimg  20151030-14:19 aballier  ce7e1fd
net-misc/libres3 20151016-13:25 tomboy64  8d7cd07

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
net-firewall/shorewall-core,removed,idella4,20151027-03:01,ee2e65a
net-firewall/shorewall-init,removed,idella4,20151027-03:01,ee2e65a
net-firewall/shorewall-lite,removed,idella4,20151027-03:01,ee2e65a
net-firewall/shorewall6-lite,removed,idella4,20151027-03:01,ee2e65a
net-firewall/shorewall6,removed,idella4,20151027-03:01,ee2e65a
dev-java/commons-transaction,removed,chewi,20151026-23:27,b7e36ec
dev-java/proxool,removed,chewi,20151026-23:26,ca9f85a
www-servers/axis,removed,chewi,20151026-23:25,1eda279
dev-java/hibernate,removed,chewi,20151026-23:23,ada875a
dev-java/hibernate-annotations,removed,chewi,20151026-23:23,46d1933
dev-java/mx4j-tools,removed,chewi,20151026-23:16,8c6f817
dev-java/mx4j-core,removed,chewi,20151026-23:15,2bb4f77
dev-java/mx4j,removed,chewi,20151026-23:14,8a9cf23
dev-java/jax-rpc,removed,chewi,20151026-23:13,f97b65f
dev-java/commons-modeler,removed,chewi,20151026-23

Re: [gentoo-dev] Gentoo-hosted code review

[Luca Barbato]

On 01/11/15 23:07, Michael Orlitzky wrote:
> On 11/01/2015 12:44 PM, Michael Palimaka wrote:
>> There's been a lot of discussion about relying on GitHub for pull
>> requests and code review and such, so I have set up a Phabricator
>> instance against gentoo.git to see how a free alternative might work.
>>
>> ...
>>
>> What do you think?
>>
> 
> Thanks for working on this. I personally didn't like Phabricator very
> much when I used it, but I'm glad someone is trying out code review
> platforms. I could live with it.

Most of the code-review platforms are cumbersome and inefficient
depending on the purpose.

Phab has some nice ideas (gamification is one of them), but overall I
feel interacting with it less pleasant than interacting with github and
gitlab (both have different defects).

Personally I wouldn't mind having a gitlab setup if there is consensus
in going in that direction.

If we want to try to do something more simple, patchwork or plaid (from
truly yours =p) might be options as well.

lu

Re: [gentoo-dev] Re: ChangeLog

[Chí-Thanh Christopher Nguyễn]

Мисбах-Соловьёв Вадим schrieb:
>>> git clone --depth=1 
>> Now how can this user display the ChangeLog for
>> a certain package?
> ```
> git log -- pkg-category/pkg-name/

I think his point was that shallow clones don't have the full log.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] ChangeLog

[Michael Orlitzky]

On 11/01/2015 07:16 AM, Patrick Lauer wrote:
> Ahoi,
> 
> I'm getting mildly very irritated with the lack of easily accessible
> ChangeLogs for our packages.
> 
> Apparently updating them stopped some time in August, so now there are
> some outdated ChangeLogs that don't really serve any purpose, and the
> easiest way for users to figure out why something changed is to yell at
> the clumsy gitweb.g.o interface. So instead of grep we now need lots of
> patience.
> 

How about e.g. https://packages.gentoo.org/packages/dev-lang/php ?

Re: [gentoo-dev] Gentoo-hosted code review

[Michael Orlitzky]

On 11/01/2015 04:18 PM, William Hubbs wrote:
> 
> My question is this.
> 
> Does it offer interfaces other than the web -- such as an API or command
> line client?
> 
> If not, I wouldn't use it.

There's Arcanist, but there are no releases. You're supposed to clone
the git repo. Arcanist requires libphutil, and the install instructions
are basically "git clone them both to the same place." It looks like
Bertrand Jacquin may have fixed that though (up a bit in this thread).

Another problem is that Arcanist (client) and Phabricator (server) are
closely tied. So if you need to access two Phabricators, you probably
need two copies of Arcanist.

I don't want to pooh-pooh the idea too much, but I used Arcanist for GHC
and this page summarizes my experience:

  https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator

The code reviews themselves were nice, though. It's just arcanist that
gives you that feeling of "oh god something went wrong I'll just build a
new computer and start over."

Re: [gentoo-dev] ChangeLog

[Alexis Ballier]

On Sun, 1 Nov 2015 12:26:04 -0500
Rich Freeman  wrote:

> On Sun, Nov 1, 2015 at 10:24 AM, Alexis Ballier 
> wrote:
> > On Sun, 1 Nov 2015 10:17:54 -0500
> > Rich Freeman  wrote:  
> >>
> >> I haven't heard anybody propose a new plan.  I certainly am not
> >> proposing one.  
> >
> > The part you cut:
> >  
> >>
> >> You shouldn't use rsync anymore, it is inherently insecure. The git
> >> tree is _properly_ gpg signed so you can verify it's correctness.
> >>  
> 
> That was just a random developer offering random advice.  People are
> welcome to do that on the lists.  Nobody is preventing anybody from
> fixing the bug.
> 
> There is no approved grandiose plan to obsolete rsync.

Hence me asking where the discussion took place...
Y'know, the email you replied to :)

Re: [gentoo-dev] Gentoo-hosted code review

[Michael Orlitzky]

On 11/01/2015 12:44 PM, Michael Palimaka wrote:
> There's been a lot of discussion about relying on GitHub for pull
> requests and code review and such, so I have set up a Phabricator
> instance against gentoo.git to see how a free alternative might work.
> 
> ...
> 
> What do you think?
> 

Thanks for working on this. I personally didn't like Phabricator very
much when I used it, but I'm glad someone is trying out code review
platforms. I could live with it.

The big question for me is, does the apache user have write access to
the gentoo.git repo? If it does, are we all comfortable with allowing a
bajillion-line PHP application unchecked access to our repo? That's the
serious problem I see with Gerrit, Gitlab and the rest.

Re: [gentoo-dev] Gentoo-hosted code review

[hasufell]

On 11/01/2015 08:50 PM, Manuel Rüger wrote:
> On 01.11.2015 20:23, hasufell wrote:
>> On 11/01/2015 06:44 PM, Michael Palimaka wrote:
>>> There's been a lot of discussion about relying on GitHub for pull
>>> requests and code review and such, so I have set up a Phabricator
>>> instance against gentoo.git to see how a free alternative might work.
>>>
>>> Here's a few examples of how things could work:
>>>
>>> General post-commit review:
>>> http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca
>>>
>>> Tracking commits with issues that need attention:
>>> http://phabricator.astralcloak.net/audit/query/open/
>>>
>>> Pre-commit review: http://phabricator.astralcloak.net/D1
>>>
>>> Phabricator also has all sorts of fancy (optional) features that could
>>> be useful for collaborative development (see http://phabricator.org/ for
>>> more info).
>>>
>>> What do you think?
>>>
>>>
>>
>> phabricator is horrible. I'll definitely use it less (if at all) than
>> bugzilla.
>>
> 
> On 10.10.2015 16:15, Julian Ospald wrote:
>> That's a great start for us, having developers announce publicly that
>> they will ignore our project or require us to create bugs for every
>> missing "|| die" in an ebuild.
> 
> *chuckles*
> 
> 

I don't know how you confuse your ignorant behavior of blacklisting a
whole project with the liberty of gentoo developers to choose the
contribution platform which fits best for their use case (be it email,
IRC, bugzilla, phabricator or github).

But I didn't expect any different behavior from you. I think you should
re-read our CoC and stop posting mails that are just flame.

[gentoo-dev] Re: ChangeLog

[Martin Vaeth]

Rich Freeman  wrote:
>
> Keep in mind that "resources" is a vague term [...]
> disk io and CPU to sync [...]

For syncing, I think these latter resources are less important,
because they influence only the *time* of a syncing action,
which is normally not so important for the user.

Bandwidth and (effective) harddisk space are more crucial IMHO.
For the latter, we have a _clear_ winner: squashdelta
(which BTW could also be signed).

Concerning bandwidth, comparison is harder - it varies for
the different methods dramatically on how often you sync -
but squashdelta is also not bad here.

At least the mentioned problems with connection loss can
be solved easily for squashdelta, too, because only one
file has to be transferred whose transfer might be resumed.

Re: [gentoo-dev] Gentoo-hosted code review

[William Hubbs]

On Sun, Nov 01, 2015 at 08:23:22PM +0100, hasufell wrote:
> On 11/01/2015 06:44 PM, Michael Palimaka wrote:
> > There's been a lot of discussion about relying on GitHub for pull
> > requests and code review and such, so I have set up a Phabricator
> > instance against gentoo.git to see how a free alternative might work.
> > 
> > Here's a few examples of how things could work:
> > 
> > General post-commit review:
> > http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca
> > 
> > Tracking commits with issues that need attention:
> > http://phabricator.astralcloak.net/audit/query/open/
> > 
> > Pre-commit review: http://phabricator.astralcloak.net/D1
> > 
> > Phabricator also has all sorts of fancy (optional) features that could
> > be useful for collaborative development (see http://phabricator.org/ for
> > more info).
> > 
> > What do you think?
> > 
> > 

My question is this.

Does it offer interfaces other than the web -- such as an API or command
line client?

If not, I wouldn't use it.

Thanks,

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: ChangeLog

[Rich Freeman]

On Sun, Nov 1, 2015 at 3:33 PM, Martin Vaeth  wrote:
> Please do not break all these possibilities for users
> who do not have to waste the resources for a full git
> clone and want to see regularly ChangeLogs nevertheless!

I don't think anybody has proposed breaking anything.  It sounds like
it is already broken, and somebody needs to fix it.

Keep in mind that "resources" is a vague term and for some resources
either git or rsync can be cheaper.  Rsync will tend to require less
local disk space than git (unless you try to purge all the history out
of the repositories, which of course defeats the goal of having
Changelogs).  On the other hand, git should require far less disk io
and CPU to sync since it doesn't have to rely on stat-ing every file
(and if you want rsync to be truly reliable you need to tell it to
hash everything which adds a boatload of additional IO - git doesn't
rely on mtime).

-- 
Rich

Re: [gentoo-dev] Re: ChangeLog

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11/01/2015 09:33 PM, Martin Vaeth wrote:
> Мисбах-Соловьёв Вадим  wrote:
>>> Perhaps there is a better choice of distribution for you if you
>>> are.
>> 
>> Or you can just... use rsync.
> 
> Or emerge-webrsync, emerge-delta-webrsync or squashdelta (I
> strongly hope that the latter will be available again in some
> future - IMHO it is perfect for most users).
> 
> Please do not break all these possibilities for users who do not
> have to waste the resources for a full git clone and want to see
> regularly ChangeLogs nevertheless!
> 
> 


I wouldn't be too worried about that, although I do hope that we get
proper OpenPGP signing[0] into the main tree sooner rather than later.

References:
[0] https://wiki.gentoo.org/wiki/Project:Gentoo-keys

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWNngoAAoJECULev7WN52F+g0H+wW9EuEbz6xwg+4s/lET8uau
86WOJQTFSAuvYuaqVT0gwbY0v+0CCDg+nsaIRnl+jRJWcFuZ9Wbu1H/ehWaJ5sVK
a1Q1aTakuc/szMZS3zQpykUG1PUNkyCXtKxA5ubsUcagPfBD7yjkFZ9/CrHiIUoF
u8oXi+hGCOpIpS6hjizMUuBiJTiXu3cbb7/BKqZ2Lz234kumfMAPDd95CYMCaayC
33NFQitP1d1dhk0z9O5LrrIyHBrXbQF/hbTY/oxsuZ95Cn4JdmU2GUQriHzvraPy
iZGgYRxUXPh/0PQNsdSV4YIWUb9CwmA8vfkLnND+hs3haE3U63uBUjiMDznIukA=
=lFUN
-END PGP SIGNATURE-

[gentoo-dev] Re: ChangeLog

[Martin Vaeth]

Мисбах-Соловьёв Вадим  wrote:
>> Perhaps there is a better choice of distribution for you if you are.
>
> Or you can just... use rsync.

Or emerge-webrsync, emerge-delta-webrsync or squashdelta
(I strongly hope that the latter will be available again
in some future - IMHO it is perfect for most users).

Please do not break all these possibilities for users
who do not have to waste the resources for a full git
clone and want to see regularly ChangeLogs nevertheless!

[gentoo-dev] Re: ChangeLog

[Martin Vaeth]

Мисбах-Соловьёв Вадим  wrote:
>
>> Now how can this user display the ChangeLog for
>> a certain package?
> ```
> git log -- pkg-category/pkg-name/

You removed the crucial part of my posting:

>> git clone --depth=1

Re: [gentoo-dev] Gentoo-hosted code review

[Manuel Rüger]

On 01.11.2015 20:23, hasufell wrote:
> On 11/01/2015 06:44 PM, Michael Palimaka wrote:
>> There's been a lot of discussion about relying on GitHub for pull
>> requests and code review and such, so I have set up a Phabricator
>> instance against gentoo.git to see how a free alternative might work.
>>
>> Here's a few examples of how things could work:
>>
>> General post-commit review:
>> http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca
>>
>> Tracking commits with issues that need attention:
>> http://phabricator.astralcloak.net/audit/query/open/
>>
>> Pre-commit review: http://phabricator.astralcloak.net/D1
>>
>> Phabricator also has all sorts of fancy (optional) features that could
>> be useful for collaborative development (see http://phabricator.org/ for
>> more info).
>>
>> What do you think?
>>
>>
> 
> phabricator is horrible. I'll definitely use it less (if at all) than
> bugzilla.
> 

On 10.10.2015 16:15, Julian Ospald wrote:
> That's a great start for us, having developers announce publicly that
> they will ignore our project or require us to create bugs for every
> missing "|| die" in an ebuild.

*chuckles*




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo-hosted code review

[hydra]

On Sun, Nov 1, 2015 at 7:34 PM, Michał Górny  wrote:

>
> Does it actually support pull requests at all? All I was able to find
> was ability to paste a diff...
>
>
Phabricator supports both pre-commit code review and post-commit code
review. It's not a pull request, but code review (via the differential
tool). The post-commit code review is done via the audit tool.

Re: [gentoo-dev] Gentoo-hosted code review

[hasufell]

On 11/01/2015 06:44 PM, Michael Palimaka wrote:
> There's been a lot of discussion about relying on GitHub for pull
> requests and code review and such, so I have set up a Phabricator
> instance against gentoo.git to see how a free alternative might work.
> 
> Here's a few examples of how things could work:
> 
> General post-commit review:
> http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca
> 
> Tracking commits with issues that need attention:
> http://phabricator.astralcloak.net/audit/query/open/
> 
> Pre-commit review: http://phabricator.astralcloak.net/D1
> 
> Phabricator also has all sorts of fancy (optional) features that could
> be useful for collaborative development (see http://phabricator.org/ for
> more info).
> 
> What do you think?
> 
> 

phabricator is horrible. I'll definitely use it less (if at all) than
bugzilla.

Re: [gentoo-dev] Gentoo-hosted code review

[Michał Górny]

On Mon, 2 Nov 2015 04:44:39 +1100
Michael Palimaka  wrote:

> There's been a lot of discussion about relying on GitHub for pull
> requests and code review and such, so I have set up a Phabricator
> instance against gentoo.git to see how a free alternative might work.
> 
> Here's a few examples of how things could work:
> 
> General post-commit review:
> http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca
> 
> Tracking commits with issues that need attention:
> http://phabricator.astralcloak.net/audit/query/open/
> 
> Pre-commit review: http://phabricator.astralcloak.net/D1
> 
> Phabricator also has all sorts of fancy (optional) features that could
> be useful for collaborative development (see http://phabricator.org/ for
> more info).
> 
> What do you think?

At a first glance -- terribly unreadable, wtf is all that tiny stuff
thrown at me all at once? But I guess we can get used to it, or get
some kind of sane theme. Tiny, gray text on a little brighter gray
background with some more shades of gray-cyan around doesn't help
readability at all.

What's the deal with 'rGENTOO56bd759df1d0'? Can't it be made to use
normal commit hashes, or at least put some separator in that? I know
enlightenment people like this kind of stuff but it's neither friendly,
not readable. And it's going to make copy-paste harder.

Second thought, it's slow. I mean, I open a directory and wait a few
seconds for detailed information to appear, with my CPU getting hot for
no good reason. I can only guess how hot the server gets in the
meantime...

GitHub registration is a nice touch. Sad you need to retype the e-mail
address though.

Again, the GUI is far from intuitive. Can inline comments be added only
in diff mode? Since it doesn't want to show the diff for 'huge'
commits, this prevents us from commenting in some contexts.

Does it actually support pull requests at all? All I was able to find
was ability to paste a diff...

-- 
Best regards,
Michał Górny



pgpbPoowVPFwa.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo-hosted code review

[Bertrand Jacquin]

You might be interested in a few ebuild I made for it for Enlightenment:

http://git.meleeweb.net/gentoo/portage.git/tree/dev-php/libphutil
http://git.meleeweb.net/gentoo/portage.git/tree/www-client/arcanist
http://git.meleeweb.net/gentoo/portage.git/tree/www-apps/phabricator

Cheers

On 01/11/2015 17:44, Michael Palimaka wrote:

There's been a lot of discussion about relying on GitHub for pull
requests and code review and such, so I have set up a Phabricator
instance against gentoo.git to see how a free alternative might work.

Here's a few examples of how things could work:

General post-commit review:
http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca

Tracking commits with issues that need attention:
http://phabricator.astralcloak.net/audit/query/open/

Pre-commit review: http://phabricator.astralcloak.net/D1

Phabricator also has all sorts of fancy (optional) features that could
be useful for collaborative development (see http://phabricator.org/ 
for

more info).

What do you think?


--
Bertrand

Re: [gentoo-dev] Gentoo-hosted code review

[James Le Cuirot]

On Mon, 2 Nov 2015 04:44:39 +1100
Michael Palimaka  wrote:

> Phabricator also has all sorts of fancy (optional) features that could
> be useful for collaborative development (see http://phabricator.org/
> for more info).
> 
> What do you think?

Looks nice! I hadn't heard of Phabricator before. It has a good mix of
open and closed projects using it, according to Wikipedia. I'm using
GitLab at work, which also does the job but Phabricator would probably
scale easier being PHP-based rather than Ruby-based; I say that as a
Ruby developer! I've had Gerrit recommended a few times but while I'm
sure it's capable, my brief encounters with it have found the interface
a little overwhelming.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpEwqbKFIfeO.pgp
Description: OpenPGP digital signature

[gentoo-dev] Gentoo-hosted code review

[Michael Palimaka]

There's been a lot of discussion about relying on GitHub for pull
requests and code review and such, so I have set up a Phabricator
instance against gentoo.git to see how a free alternative might work.

Here's a few examples of how things could work:

General post-commit review:
http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca

Tracking commits with issues that need attention:
http://phabricator.astralcloak.net/audit/query/open/

Pre-commit review: http://phabricator.astralcloak.net/D1

Phabricator also has all sorts of fancy (optional) features that could
be useful for collaborative development (see http://phabricator.org/ for
more info).

What do you think?

Re: [gentoo-dev] Re: ChangeLog

[Rich Freeman]

On Sun, Nov 1, 2015 at 10:29 AM, Martin Vaeth  wrote:
> Rich Freeman  wrote:
>>
>> What discussion or decision is necessary?
>> What is needed is for those who want changelogs
>> to fix the bug
>
> The bug can only be fixed by somebody who knows
> the details how the rsync mirrors are set up.

And that is really the bigger problem here.  I think we really need to
minimize dependency on stuff that only a few people have access to,
since they're overworked.  I'd certainly encourage somebody to offer
up a fixed rsync server.  While you're at it, a gitlab/whatever server
so that we don't have to keep arguing over github would also be nice.

I'd really like to see our infrastructure get to a point where it is
all published FOSS minus maybe a few authentication tokens so that
anybody can just fork it on demand.  Even though we'd probably still
want the officially-designated servers it would make it far easier for
others to contribute if they could actually test it all out.
Authentication could use openid or whatever so that a clone could be a
first-class alternative.

In any case though, this isn't some vast conspiracy to get rid of
Changelogs.  More likely there are only a few people who can fix them,
and they simply haven't gotten around to it.

-- 
Rich

Re: [gentoo-dev] ChangeLog

[Rich Freeman]

On Sun, Nov 1, 2015 at 10:24 AM, Alexis Ballier  wrote:
> On Sun, 1 Nov 2015 10:17:54 -0500
> Rich Freeman  wrote:
>>
>> I haven't heard anybody propose a new plan.  I certainly am not
>> proposing one.
>
> The part you cut:
>
>>
>> You shouldn't use rsync anymore, it is inherently insecure. The git
>> tree is _properly_ gpg signed so you can verify it's correctness.
>>

That was just a random developer offering random advice.  People are
welcome to do that on the lists.  Nobody is preventing anybody from
fixing the bug.

There is no approved grandiose plan to obsolete rsync.

-- 
Rich

Re: [gentoo-dev] Re: ChangeLog

[Мисбах-Соловьёв Вадим]

> Perhaps there is a better choice of distribution for you if you are.

Or you can just... use rsync.

Re: [gentoo-dev] Re: ChangeLog

[Ciaran McCreesh]

On Sun, 01 Nov 2015 22:19:24 +0600
Мисбах-Соловьёв Вадим  wrote:
> > Now how can this user display the ChangeLog for
> > a certain package?
> ```
> git log -- pkg-category/pkg-name/
> ```
> // assuming user in portage directory or passed GIT_DIR with path to
> it.
> 
> Although, it is only if user has successfully cloned/synced the
> repo ;) Which is hardcore quest when you're living in, say, Syria,
> Egypt, Somalia, or something like that. Or, if you're, say, in
> transsiberian train ride for a week.

Perhaps there is a better choice of distribution for you if you are.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: ChangeLog

[Мисбах-Соловьёв Вадим]

> Now how can this user display the ChangeLog for
> a certain package?
```
git log -- pkg-category/pkg-name/
```
// assuming user in portage directory or passed GIT_DIR with path to it.

Although, it is only if user has successfully cloned/synced the repo ;)
Which is hardcore quest when you're living in, say, Syria, Egypt, Somalia, or 
something like that. Or, if you're, say, in transsiberian train ride for a week.

Re: [gentoo-dev] ChangeLog

[Мисбах-Соловьёв Вадим]

> git clone --depth=1 (you can also put that into your repos.conf, the
> option is called 'sync-depth'). --depth is also available for regular pulls.
```
$ LC_ALL=C git clone --depth=1 git://git.gentoo.org/repo/gentoo.git
Cloning into 'gentoo'...
remote: Counting objects: 113359, done.
remote: Compressing objects: 100% (99921/99921), done.
Receiving objects:  17% (19272/113359), 7.32 MiB | 30 KiB/s
# 

$ LC_ALL=C ls gentoo
ls: cannot access gentoo: No such file or directory
```

So? How should I sync then? Git can *not* sync file by file, while rsync can.

> And thanks for calling me selfish for trying to make it possible for
> users to directly use a git checkout as the local tree. I appreciate it. :)

No. Making it *possible* for all users to use git (instead of old cvs+rsync 
behaviour) is a great thing and you're awesome in making it *possible*. But do 
not be authoritarian and do not *force* (!) users to "use only git and forget 
about rsync".

I called you selfish not for doing good things like introducing possibility to 
use git, but for authoritarian thinking, that all users has as good internet 
connection (taking that thread) or tech. knowledge (talking prev. threads) as 
you. They are not. At least, far not always.

[gentoo-dev] Re: ChangeLog

[Martin Vaeth]

hasufell  wrote:
>
> git clone --depth=1

The only reasonable option for the gentoo user
(not for the gentoo developer) if he does not have
megabytes to waste on his harddisk (which probably
many users don't), if you want to *force* him
to use git.

Now how can this user display the ChangeLog for
a certain package?

[gentoo-dev] Re: ChangeLog

[Martin Vaeth]

Rich Freeman  wrote:
>
> What discussion or decision is necessary?
> What is needed is for those who want changelogs
> to fix the bug

The bug can only be fixed by somebody who knows
the details how the rsync mirrors are set up.

As mentioned in the discussion in bug 561454,
*essentially* all it needs to fix the issue is to call

egencache --repo=gentoo --update-changelog

on the main server providing the data for the mirrors,
but details (e.g. when to call it) depend on how
exactly the server is organized.

For instance, it might be necessary to put
ChangeLog
/.gitignore
into a local .gitignore file or something similar,
and somehow the Manifests due to modified ChangeLogs
might need to be updated, too.

Re: [gentoo-dev] ChangeLog

[Alexis Ballier]

On Sun, 1 Nov 2015 10:17:54 -0500
Rich Freeman  wrote:

> On Sun, Nov 1, 2015 at 10:00 AM, Alexis Ballier 
> wrote:
> > On Sun, 1 Nov 2015 09:19:25 -0500
> > Rich Freeman  wrote:
> >
> > [...]  
> >> What discussion or decision is necessary?  
> >
> > One that announces the initial and current plan has changed and
> > describes the new plan maybe?
> >  
> 
> I haven't heard anybody propose a new plan.  I certainly am not
> proposing one.

The part you cut:

> 
> You shouldn't use rsync anymore, it is inherently insecure. The git
> tree is _properly_ gpg signed so you can verify it's correctness.
> 
> With the following portage configuration/hooks, any user can run the
> tree directly from git:
> https://github.com/hasufell/portage-gentoo-git-config  

Re: [gentoo-dev] ChangeLog

[Rich Freeman]

On Sun, Nov 1, 2015 at 10:00 AM, Alexis Ballier  wrote:
> On Sun, 1 Nov 2015 09:19:25 -0500
> Rich Freeman  wrote:
>
> [...]
>> What discussion or decision is necessary?
>
> One that announces the initial and current plan has changed and
> describes the new plan maybe?
>

I haven't heard anybody propose a new plan.  I certainly am not proposing one.

Like I said, I don't have a problem with there being Changelogs in
rsync.  By all means go fix it.

-- 
Rich

Re: [gentoo-dev] ChangeLog

[Alexis Ballier]

On Sun, 1 Nov 2015 09:19:25 -0500
Rich Freeman  wrote:

[...]
> What discussion or decision is necessary?

One that announces the initial and current plan has changed and
describes the new plan maybe?

[...]
> So, if you want to see what has changed there are half a dozen ways of
> doing it without using changelogs.


I imagine the 'you' in your long tirade is a generic 'you', otherwise,
let me make this clear: I'm in favor of removing changelogs. They made
sense with the per-file tracking of cvs, git made them much less useful.

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-python/scientificpython

[Justin Lecher (jlec)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Justin Lecher  (01 Nov 2015)
# Obsolete package
# Incompatible to recent numpy version
# No upstream activity
dev-python/scientificpython
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0

iQJ8BAEBCgBmBQJWNiehXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmivfUP/0qFS2mNj3TKJyb127cpGRn1
6A1BWrEnuBkpu3baSB11T/9aL8NgO0HRzO9rhjJ+pbDXBUgExqphefE9vy7zy5GP
QuyG7+dan+UNac4WKDDvAuFHpx4Jx5MpnW/tPMAFX7dr5/tTsQitYz8azVeOMVRM
t2iqPkUcIYAy6hhQdU2KgT/FYQB9DtTm+MDWeEM7XwIQMcBUDvg8rxv0NihEAoll
5jmXKUJd+3YRGYBJ/INtoDCt88Qg/VUbxuvmDiJSWwLB7IKLsfYlES7hSkLak6bl
GqOWWadxrSUwz43yH5hlsjxqLDZBBnLlCh29OTsz2ZZzA+Sl0o8pcAzs9YBv34VA
n6ZC5fuvAONu4byQSf1IUK4imqDcg3escTqCijUEuTXJSZlkTD0sQ3fbR5vwRvmj
2ndtsEt+DxE+wXQ6e16nYjoQc9D0+zLjN7xch0nX7uEbUjpFR1llLa7H7KlHxLsP
DYLBLo+eK5s8K8m/d2IRAJFT1e73jryK8CqJDAlslQthX1pcwpwQF/vZqsT0rfOK
JvMiTqq9QMZVFBq6ILm8A1MZ8kuXauyrfPZdwrKoLhaVnAcSnqHn9I7x2UqZ67vg
u7gGYEWhGw7Zj5snzIfh0wZkhnzJp7zPxJlgHXmVxvGPu5ik2Os/Sp9DS6gAYA4/
B2IKpZeam4oOdLkjXpIK
=4DLE
-END PGP SIGNATURE-

Re: [gentoo-dev] ChangeLog

[Rich Freeman]

On Sun, Nov 1, 2015 at 8:47 AM, Alexis Ballier  wrote:
> Considering the original plan was to have changelogs auto-generated
> from git and still serving the tree via rsync, where's the relevant
> discussion and decision about this?

What discussion or decision is necessary?  As far as I'm aware nobody
has forbidden making changelogs available via rsync.  It just sounds
like there is a bug in their generation.  What is needed is for those
who want changelogs to fix the bug, not endless discussion.  If the
issue is infra access, just make your own mirror with working code and
I'm sure infra will borrow it, and if not nobody really HAS to use
infra.  I'm syncing from the github mirror that contains pre-generated
metadata for convenience, which is just one of the many options
available.

Nobody is actively preventing anybody from having what they want.
This isn't some corporation where we are paying people and we can
demand that the responsible parties fix things or lose their jobs.

Lots of effort has gone into making the git migration as seamless as
possible, but it was bound to be imperfect.  Personally I would have
been fine with less effort being spent on it than actually was.
Gentoo has never been a hand-holding distro.  I have nothing against
people who choose to invest their time into making it more helpful to
those who wish to use alternate tools (like changelogs), but I don't
favor telling those who are working on new features to not actually
deploy them unless THEY spend their time on such things as long as we
have a reasonable path forward for everybody.

So, if you want to see what has changed there are half a dozen ways of
doing it without using changelogs.

-- 
Rich

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/01/2015 02:51 PM, Мисбах-Соловьёв Вадим wrote:
>> You shouldn't use rsync anymore, it is inherently insecure. The git tree
>> is _properly_ gpg signed so you can verify it's correctness.
>>
>> With the following portage configuration/hooks, any user can run the
>> tree directly from git:
>> https://github.com/hasufell/portage-gentoo-git-config
>>
>> At some point, rsync schould be deprecated completely.
> 
> Nice try, but sometimes (say, in case of very unstable internet connection) 
> it is IMPOSSIBLE to properly sync git repo (because it tries to fetch all the 
> queue (between local HEAD and remote one) in a row, from the exactly same 
> place every time it fails), while it still possible to sync tree by rsync, 
> because it only fetches differences and do not drop properly downloaded files.
> 
> Do NOT (!) assume flawless shiny 40Gbit internet everywhere in the world. 
> Stop being so selfish and thinking only from position of the developer. 
> Always do imagine you as the gentoo user in the worst possible case.
> Please.
> 

git clone --depth=1 (you can also put that into your repos.conf, the
option is called 'sync-depth'). --depth is also available for regular pulls.

And thanks for calling me selfish for trying to make it possible for
users to directly use a git checkout as the local tree. I appreciate it. :)

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/01/2015 02:47 PM, Alexis Ballier wrote:
> On Sun, 1 Nov 2015 14:33:07 +0100
> hasufell  wrote:

 git log -- app-misc/foo
 or
 git log -- eclass/autotools.eclass

 will give you _any_ commit that has touched that file/directory,
 even if it was part of a huge mass commit.  
>>>
>>>  $ cd /usr/portage/app-admin/rex/; git log
>>> fatal: Not a git repository (or any of the parent directories): .git
>>>
>>> sooo ... ???
>>>   
>>
>> You shouldn't use rsync anymore, it is inherently insecure. The git
>> tree is _properly_ gpg signed so you can verify it's correctness.
>>
>> With the following portage configuration/hooks, any user can run the
>> tree directly from git:
>> https://github.com/hasufell/portage-gentoo-git-config
> 
> More secure by fetching metadata cache via rsync ?
> Better by running egencache after each sync ?
> I don't think so.
> 

Yes it is. You have the option of generating it yourself (only takes
long for the first time) or fetch it from the following gentoo mirror
instead https://github.com/gentoo-mirror/gentoo

We might adjust those hooks to do that.

>> At some point, rsync schould be deprecated completely.
> 
> 
> Considering the original plan was to have changelogs auto-generated
> from git and still serving the tree via rsync, where's the relevant
> discussion and decision about this?
> 
> There's no technical reason for not doing this *today*, the only reason
> not to is the lack of decision and concrete plan on how to properly
> serve what is in the rsync'ed tree and not in gentoo.git.
> 
> 
> Until then, we are serving outdated and useless changelogs via rsync
> and Patrick's point still holds: Either remove them or serve proper
> ones.
> 

+1 for removing.

Re: [gentoo-dev] ChangeLog

[Мисбах-Соловьёв Вадим]

> You shouldn't use rsync anymore, it is inherently insecure. The git tree
> is _properly_ gpg signed so you can verify it's correctness.
>
> With the following portage configuration/hooks, any user can run the
> tree directly from git:
> https://github.com/hasufell/portage-gentoo-git-config
>
> At some point, rsync schould be deprecated completely.

Nice try, but sometimes (say, in case of very unstable internet connection) it 
is IMPOSSIBLE to properly sync git repo (because it tries to fetch all the 
queue (between local HEAD and remote one) in a row, from the exactly same place 
every time it fails), while it still possible to sync tree by rsync, because it 
only fetches differences and do not drop properly downloaded files.

Do NOT (!) assume flawless shiny 40Gbit internet everywhere in the world. Stop 
being so selfish and thinking only from position of the developer. Always do 
imagine you as the gentoo user in the worst possible case.
Please.

Re: [gentoo-dev] ChangeLog

[Alexis Ballier]

On Sun, 1 Nov 2015 14:33:07 +0100
hasufell  wrote:
> >>
> >> git log -- app-misc/foo
> >> or
> >> git log -- eclass/autotools.eclass
> >>
> >> will give you _any_ commit that has touched that file/directory,
> >> even if it was part of a huge mass commit.  
> > 
> >  $ cd /usr/portage/app-admin/rex/; git log
> > fatal: Not a git repository (or any of the parent directories): .git
> > 
> > sooo ... ???
> >   
> 
> You shouldn't use rsync anymore, it is inherently insecure. The git
> tree is _properly_ gpg signed so you can verify it's correctness.
> 
> With the following portage configuration/hooks, any user can run the
> tree directly from git:
> https://github.com/hasufell/portage-gentoo-git-config

More secure by fetching metadata cache via rsync ?
Better by running egencache after each sync ?
I don't think so.

> At some point, rsync schould be deprecated completely.


Considering the original plan was to have changelogs auto-generated
from git and still serving the tree via rsync, where's the relevant
discussion and decision about this?

There's no technical reason for not doing this *today*, the only reason
not to is the lack of decision and concrete plan on how to properly
serve what is in the rsync'ed tree and not in gentoo.git.


Until then, we are serving outdated and useless changelogs via rsync
and Patrick's point still holds: Either remove them or serve proper
ones.


Alexis.

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/01/2015 02:28 PM, Patrick Lauer wrote:
>>
>> ChangeLogs are a deprecated and unreliable method of the times we were
>> still on CVS. E.g. some people didn't find it useful to add ChangeLog
>> entries when they did large eclass changes. This problem is gone now.
> ... ?!??!#??$>@%%*%**%@!!!
> 
> From the point of view of a user ChangeLogs are VERY VERY USEFUL.
> 
> Why would you claim they are deprecated?

Because they are unreliable and we have a better method.

>>
>> git log -- app-misc/foo
>> or
>> git log -- eclass/autotools.eclass
>>
>> will give you _any_ commit that has touched that file/directory, even if
>> it was part of a huge mass commit.
> 
>  $ cd /usr/portage/app-admin/rex/; git log
> fatal: Not a git repository (or any of the parent directories): .git
> 
> sooo ... ???
> 

You shouldn't use rsync anymore, it is inherently insecure. The git tree
is _properly_ gpg signed so you can verify it's correctness.

With the following portage configuration/hooks, any user can run the
tree directly from git:
https://github.com/hasufell/portage-gentoo-git-config

At some point, rsync schould be deprecated completely.

Re: [gentoo-dev] ChangeLog

[Patrick Lauer]

On 11/01/2015 02:24 PM, hasufell wrote:
> On 11/01/2015 01:16 PM, Patrick Lauer wrote:
>> Ahoi,
>>
>> I'm getting mildly very irritated with the lack of easily accessible
>> ChangeLogs for our packages.
>>
>> Apparently updating them stopped some time in August, so now there are
>> some outdated ChangeLogs that don't really serve any purpose, and the
>> easiest way for users to figure out why something changed is to yell at
>> the clumsy gitweb.g.o interface. So instead of grep we now need lots of
>> patience.
>>
>> This does not look reasonable to me.
>>
>> Can we please either properly remove ChangeLogs and tell people to not
>> be curious about changes, or make them useful again?
>>
>
> ChangeLogs are a deprecated and unreliable method of the times we were
> still on CVS. E.g. some people didn't find it useful to add ChangeLog
> entries when they did large eclass changes. This problem is gone now.
... ?!??!#??$>@%%*%**%@!!!

>From the point of view of a user ChangeLogs are VERY VERY USEFUL.

Why would you claim they are deprecated?
>
> git log -- app-misc/foo
> or
> git log -- eclass/autotools.eclass
>
> will give you _any_ commit that has touched that file/directory, even if
> it was part of a huge mass commit.

 $ cd /usr/portage/app-admin/rex/; git log
fatal: Not a git repository (or any of the parent directories): .git

sooo ... ???

>
> There's really not much ChangeLogs add for you here, except duplicating
> git functionality. It's more useful to familiarize yourself with git
> log. There's no reason to depend on the gitweb interface.
>
> If you want the history from before the migration to work with that as
> well, you can use this method:
> https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Grafting_Gentoo_History_Onto_the_Active_Repo
>
> Also see
> https://www.atlassian.com/git/tutorials/git-log/filtering-the-commit-history
>
I have no idea what you are trying to say, but for most users this
advice is not even useless but actively wrong.

With that out of the way,

can we please return to the original discussion?

Re: [gentoo-dev] ChangeLog

[Patrick Lauer]

On 11/01/2015 01:53 PM, Rich Freeman wrote:
> On Sun, Nov 1, 2015 at 7:33 AM, Мисбах-Соловьёв Вадим  wrote:
>> And why don't just only generate them on rsync mirrors, but remove them from 
>> git repo (like was planned initially, AFAIRC)?
>>
> That is in fact how it works.  Or, at least how it is supposed to
> work.  I don't use the rsync mirror, so I can't vouch for whether
> they're producing ChangeLogs.
Supposed to, but it doesn't
>
> Personally I'd just as soon see them go away entirely, but if somebody
> wants to make them work I won't stop them.
>
I'd really not prefer to fly blind, ChangeLogs are awesome for users.

I am a user too. I really would like to know why something changed, and
maybe who did it.

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/01/2015 01:16 PM, Patrick Lauer wrote:
> Ahoi,
> 
> I'm getting mildly very irritated with the lack of easily accessible
> ChangeLogs for our packages.
> 
> Apparently updating them stopped some time in August, so now there are
> some outdated ChangeLogs that don't really serve any purpose, and the
> easiest way for users to figure out why something changed is to yell at
> the clumsy gitweb.g.o interface. So instead of grep we now need lots of
> patience.
> 
> This does not look reasonable to me.
> 
> Can we please either properly remove ChangeLogs and tell people to not
> be curious about changes, or make them useful again?
> 


ChangeLogs are a deprecated and unreliable method of the times we were
still on CVS. E.g. some people didn't find it useful to add ChangeLog
entries when they did large eclass changes. This problem is gone now.

git log -- app-misc/foo
or
git log -- eclass/autotools.eclass

will give you _any_ commit that has touched that file/directory, even if
it was part of a huge mass commit.

There's really not much ChangeLogs add for you here, except duplicating
git functionality. It's more useful to familiarize yourself with git
log. There's no reason to depend on the gitweb interface.

If you want the history from before the migration to work with that as
well, you can use this method:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Grafting_Gentoo_History_Onto_the_Active_Repo

Also see
https://www.atlassian.com/git/tutorials/git-log/filtering-the-commit-history

Re: [gentoo-dev] ChangeLog

[Rich Freeman]

On Sun, Nov 1, 2015 at 7:33 AM, Мисбах-Соловьёв Вадим  wrote:
> And why don't just only generate them on rsync mirrors, but remove them from 
> git repo (like was planned initially, AFAIRC)?
>

That is in fact how it works.  Or, at least how it is supposed to
work.  I don't use the rsync mirror, so I can't vouch for whether
they're producing ChangeLogs.

Personally I'd just as soon see them go away entirely, but if somebody
wants to make them work I won't stop them.

-- 
Rich

Re: [gentoo-dev] ChangeLog

[Мисбах-Соловьёв Вадим]

And why don't just only generate them on rsync mirrors, but remove them from 
git repo (like was planned initially, AFAIRC)?

01.11.2015, 18:17, "Patrick Lauer" :
> Ahoi,
>
> I'm getting mildly very irritated with the lack of easily accessible
> ChangeLogs for our packages.
>
> Apparently updating them stopped some time in August, so now there are
> some outdated ChangeLogs that don't really serve any purpose, and the
> easiest way for users to figure out why something changed is to yell at
> the clumsy gitweb.g.o interface. So instead of grep we now need lots of
> patience.
>
> This does not look reasonable to me.
>
> Can we please either properly remove ChangeLogs and tell people to not
> be curious about changes, or make them useful again?
>
> Thanks,
>
> A Gentoo User.

Re: [gentoo-dev] ChangeLog

[Anthony G. Basile]

On 11/1/15 7:16 AM, Patrick Lauer wrote:

Ahoi,

I'm getting mildly very irritated with the lack of easily accessible
ChangeLogs for our packages.

Apparently updating them stopped some time in August, so now there are
some outdated ChangeLogs that don't really serve any purpose, and the
easiest way for users to figure out why something changed is to yell at
the clumsy gitweb.g.o interface. So instead of grep we now need lots of
patience.

This does not look reasonable to me.

Can we please either properly remove ChangeLogs and tell people to not
be curious about changes, or make them useful again?

Thanks,

A Gentoo User.

I don't have strong feelings about this, but I'm happy with `git log` to 
tell me what's going on with packages.  I would be okay with the 
ChangeLog files just being archived and removed.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev] ChangeLog

[Patrick Lauer]

Ahoi,

I'm getting mildly very irritated with the lack of easily accessible
ChangeLogs for our packages.

Apparently updating them stopped some time in August, so now there are
some outdated ChangeLogs that don't really serve any purpose, and the
easiest way for users to figure out why something changed is to yell at
the clumsy gitweb.g.o interface. So instead of grep we now need lots of
patience.

This does not look reasonable to me.

Can we please either properly remove ChangeLogs and tell people to not
be curious about changes, or make them useful again?

Thanks,

A Gentoo User.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ian Delaney]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 30 Oct 2015 18:20:08 +0100
Michał Górny  wrote:

> On Fri, 30 Oct 2015 12:03:59 + (UTC)
> "Justin Lecher"  wrote:
> 
> > commit: df8e399c9bac2dc30d7cf69c2462a81729a3ae69
> > Author: Justin Lecher  gentoo  org>
> > AuthorDate: Fri Oct 30 10:18:05 2015 +
> > Commit: Justin Lecher  gentoo  org>
> > CommitDate: Fri Oct 30 12:03:49 2015 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c
> > 
> > eclass: Use consistent place for then in if clause
> 
> Excuse me but who are you exactly to take a random eclass and commit
> random style changes inside without even bothering to contact
> the author?
> 

Well, what's this? he selected a random eclass? Then he recklessly
committed a random style change? To my observation, the lead recruiter
specifically selected the distutils-r1 eclass, not some random one like
base.eclass, and carefully edited a couple of lines to put "; then" at
the end of a line as is done in most any ebuild. So how RANDOM is that?
In fact it isn't, however you have no hesitation in taking him to task
not only over its randomness which isn't, but that he had the gaul to do
it at all.

Was it not you who insisted that I assign a bug over the func
distutils_install_for_testing and you insisted I assign it to the
python team, not to you as I did. You lectured me to follow the rules
stating that it belongs to the python herd / project / w/e which may
be authored by its members any time in the future. It seems you want it
both ways.

jlec is not only a member of python team but he is high ranked. That
exactly is who he is.
> Not to mention this commit message is incorrect as it doesn't state
> which eclass was modified.
> 

This is in fact correct.
> > 
> > Signed-off-by: Justin Lecher  gentoo.org>
> > 
> >  eclass/distutils-r1.eclass | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> > index 185dd4f..dbd27a7 100644
> > --- a/eclass/distutils-r1.eclass
> > +++ b/eclass/distutils-r1.eclass
> > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> >  
> > _distutils-r1_disable_ez_setup
> >  
> > -   if [[ ${DISTUTILS_IN_SOURCE_BUILD} && !
> > ${DISTUTILS_SINGLE_IMPL} ]]
> > -   then
> > +   if [[ ${DISTUTILS_IN_SOURCE_BUILD} && !
> > ${DISTUTILS_SINGLE_IMPL} ]]; then
> 
> This was intentionally wrapped to stay within 72-column line width.
> Not saying the eclass is perfect in keeping text width, especially
> with others committing random changes to it, but that's no reason to
> introduce further offenders.
> 

there's that random again. Once and for all mgorny get off your high
horse.

> > # create source copies for each implementation
> > python_copy_sources
> > fi
> > 
> 
> 
> 



- -- 
kind regards

Ian Delaney
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iKYEARECAGYFAlY0u/1fFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDdDQUM1OUY0ODkzMERBREU1NUQ1RjJBRkIy
OEVDMjEzQjgwNzJCMEQACgkQso7CE7gHKw3xZQCgyQb6Tyuw73CiBHgxXm/bvPX7
L1EAn0UfLOZTERZpMJN1VQXIgb81AkE6
=yt+k
-END PGP SIGNATURE-


-- 
kind regards

Ian Delaney