Re: Radeonhd repo not migrated to gitlab.
On Wed, Mar 13, 2019 at 06:57:10PM +0100, Luc Verhaegen wrote: > On Wed, Mar 13, 2019 at 04:24:30PM +, Daniel Stone wrote: > > In the shell script we use to generate cgitrc, we were looping over > > all the repositories and either printing a GitLab clone URL if the > > tree was mirrored from GitLab to cgit, or printing anongit clone URLs > > if not. In the former case, we were forgetting to clear the variables > > with the anongit URLs, so GitLab repos would show the anongit clone > > URLs of the last non-GitLab repo found (if any). > > > > Hence xf86-video-radeonhd appearing in some drivers (as it was > > inadvertently missed until this thread), xserver-test appearing in > > others (as it was deliberately not migrated), and xf86-video-p690 (not > > migrated as it's empty). > > So you claim that you _deliberately_ avoided migrating both xserver-test > and xf86-video-p690, and that radeonhd was _accidentally_ missed? How did your supposed gitlab migration script automatically exclude both p690 and xserver-test? Where is that script that so smartly skipped those two repositories? Surely it was kept in a git repository itself, right? Also, for large scale admin stuff, it is customary to have extensive logging. Surely this script or scripts have created logs as well. Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Wed, Mar 13, 2019 at 04:24:30PM +, Daniel Stone wrote: > Hi Kevin, > > On Wed, 13 Mar 2019 at 16:00, Kevin Brace wrote: > > I am not here to side with either one of you (i.e., Luc or you), but I have > > been wondering why some of the older, neglected (I use the word > > "underserved" to describe it) DDXs in general have weird git and ssh clone > > addresses. > > For example, Number Nine Imagine 128 DDX. > > > > [...] > > > > Why do I see this xorg/xserver-test for xorg/driver/xf86-video-i128? > > Another example will be S3 ViRGE DDX. > > > > [...] > > > > This time I see xorg/driver/xf86-video-p690. > > I probably should not get into the conspiracy theory territory, but for > > some of the underserved DDXs some months ago, the git and ssh cloning > > addresses were definitely pointing to xorg/driver/xf86-video-radeonhd. > > It was about roughly when you were working on GitLab migration. > > Considering that the history between you and Luc, is there a good > > explanation for why the cloning addresses for git and ssh were pointing to > > xorg/driver/xf86-video-radeonhd back then? > > I have been wondering if this was some kind of a prank considering the > > history of xf86-video-radeonhd. > > I do not have a personal stake in what happened between you and Luc some > > years ago, but if you can try to correct the wrong git and ssh cloning > > address issue, that will be appreciated. > > Sure, I've fixed it now, though it might take a few minutes to finish > updating. > > In the shell script we use to generate cgitrc, we were looping over > all the repositories and either printing a GitLab clone URL if the > tree was mirrored from GitLab to cgit, or printing anongit clone URLs > if not. In the former case, we were forgetting to clear the variables > with the anongit URLs, so GitLab repos would show the anongit clone > URLs of the last non-GitLab repo found (if any). > > Hence xf86-video-radeonhd appearing in some drivers (as it was > inadvertently missed until this thread), xserver-test appearing in > others (as it was deliberately not migrated), and xf86-video-p690 (not > migrated as it's empty). So you claim that you _deliberately_ avoided migrating both xserver-test and xf86-video-p690, and that radeonhd was _accidentally_ missed? Those not migrated repos stick out like sore thumbs on cgit.fd.o. More people definitely would've noticed it. And i wonder how many of them decided to either not open up the can of worms, and avoid suffering the political consequences, or who somewhat revelled in the fact that it was not migrated. I have not trawled irclogs yet to see if anyone brought it up there, like what happened in 2010: https://lists.freedesktop.org/archives/xorg/2010-November/051783.html Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
"Never attribute to malice that which is adequately explained by software bugs." -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
Hi Kevin,
On Wed, 13 Mar 2019 at 16:00, Kevin Brace wrote:
> I am not here to side with either one of you (i.e., Luc or you), but I have
> been wondering why some of the older, neglected (I use the word "underserved"
> to describe it) DDXs in general have weird git and ssh clone addresses.
> For example, Number Nine Imagine 128 DDX.
>
> [...]
>
> Why do I see this xorg/xserver-test for xorg/driver/xf86-video-i128?
> Another example will be S3 ViRGE DDX.
>
> [...]
>
> This time I see xorg/driver/xf86-video-p690.
> I probably should not get into the conspiracy theory territory, but for
> some of the underserved DDXs some months ago, the git and ssh cloning
> addresses were definitely pointing to xorg/driver/xf86-video-radeonhd.
> It was about roughly when you were working on GitLab migration.
> Considering that the history between you and Luc, is there a good explanation
> for why the cloning addresses for git and ssh were pointing to
> xorg/driver/xf86-video-radeonhd back then?
> I have been wondering if this was some kind of a prank considering the
> history of xf86-video-radeonhd.
> I do not have a personal stake in what happened between you and Luc some
> years ago, but if you can try to correct the wrong git and ssh cloning
> address issue, that will be appreciated.
Sure, I've fixed it now, though it might take a few minutes to finish updating.
In the shell script we use to generate cgitrc, we were looping over
all the repositories and either printing a GitLab clone URL if the
tree was mirrored from GitLab to cgit, or printing anongit clone URLs
if not. In the former case, we were forgetting to clear the variables
with the anongit URLs, so GitLab repos would show the anongit clone
URLs of the last non-GitLab repo found (if any).
Hence xf86-video-radeonhd appearing in some drivers (as it was
inadvertently missed until this thread), xserver-test appearing in
others (as it was deliberately not migrated), and xf86-video-p690 (not
migrated as it's empty).
I've attached the relevant shell snippet in order to hopefully calm
the conspiracy theories.
In future, if you notice anything like this, please file an issue on
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new/ and
we'll try to fix it.
Cheers,
Daniel
gitlab_mirror=$(test -d /git/${sh_wgit} && pushd
/git/${sh_wgit} >/dev/null && git config --local fdo.gitlab-mirror ||
true)
if [ -n "$gitlab_mirror" ]; then
httpsurl="https://gitlab.freedesktop.org/$gitlab_mirror;
sshurl="" # XXX this was missing
giturl="" # XXX this was missing
httpurl="" # XXX this was missing
echo "repo.desc=$desc (mirrored from $httpsurl)"
else
httpsurl=""
echo repo.desc=$desc
if [ "${url#\~}" != "$url" ]; then
sshurl="ssh://people.freedesktop.org/$url"
giturl="git://people.freedesktop.org/$url"
else
sshurl="ssh://git.freedesktop.org/git/$url"
giturl="git://anongit.freedesktop.org/$url"
fi
fi
echo "repo.clone-url=$httpsurl $giturl $sshurl $httpurl"
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
Hi Daniel, I am not here to side with either one of you (i.e., Luc or you), but I have been wondering why some of the older, neglected (I use the word "underserved" to describe it) DDXs in general have weird git and ssh clone addresses. For example, Number Nine Imagine 128 DDX. https://cgit.freedesktop.org/xorg/driver/xf86-video-i128/ -- Clone https://gitlab.freedesktop.org/xorg/driver/xf86-video-i128 git://anongit.freedesktop.org/xorg/xserver-test ssh://git.freedesktop.org/git/xorg/xserver-test https://anongit.freedesktop.org/git/xorg/driver/xf86-video-i128.git -- Why do I see this xorg/xserver-test for xorg/driver/xf86-video-i128? Another example will be S3 ViRGE DDX. https://cgit.freedesktop.org/xorg/driver/xf86-video-s3virge/ -- Clone https://gitlab.freedesktop.org/xorg/driver/xf86-video-s3virge git://anongit.freedesktop.org/xorg/driver/xf86-video-p690 ssh://git.freedesktop.org/git/xorg/driver/xf86-video-p690 https://anongit.freedesktop.org/git/xorg/driver/xf86-video-s3virge.git -- This time I see xorg/driver/xf86-video-p690. I probably should not get into the conspiracy theory territory, but for some of the underserved DDXs some months ago, the git and ssh cloning addresses were definitely pointing to xorg/driver/xf86-video-radeonhd. It was about roughly when you were working on GitLab migration. Considering that the history between you and Luc, is there a good explanation for why the cloning addresses for git and ssh were pointing to xorg/driver/xf86-video-radeonhd back then? I have been wondering if this was some kind of a prank considering the history of xf86-video-radeonhd. I do not have a personal stake in what happened between you and Luc some years ago, but if you can try to correct the wrong git and ssh cloning address issue, that will be appreciated. Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com > Date: Fri, 8 Mar 2019 06:37:21 +0900 > From: Daniel Stone > To: Adam Jackson > Cc: Luc Verhaegen , xorg-devel > > Subject: Re: Radeonhd repo not migrated to gitlab. > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > On Fri, 8 Mar 2019 at 04:35, Adam Jackson wrote: > > On Wed, 2019-03-06 at 17:04 +0100, Luc Verhaegen wrote: > > > Is there a reason why, of _all_ drivers listed in > > > > > > https://cgit.freedesktop.org/xorg/driver > > > > > > the Radeonhd repository at > > > > > > https://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/ > > > > > > has not been mirrored? > > > > Pretty sure I came up with the list of modules to migrate from the set > > I happened to have cloned locally, but it's been months. I've added a > > note to the migration ticket: > > > > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 > > ... and I've migrated it. > > FWIW, It was unique amongst all Xorg repos in that it didn't have a > .git suffix on the directory (i.e. its path was > /srv/git.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/ rather > than .../xf86-video-radeonhd.git/), which might explain it if you were > pattern-matching to list all the repos. Certainly it broke the > migration script so I had to rename it by hand first. Anyway, it's > migrated now. > > Cheers, > Daniel > > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
You really don't know when to quit do you? If you can't be civil perhaps you should leave Radeonhd is dead, xf86-video-ati only works on old hardware and the modesetting driver replaces that and wayland will make it further redundant Your work on lima helped with Panfrost but even that has far overtaken where lima ever got to Whether or not you were badly treated a decade ago doesn't excuse your behavior since then I strongly suggest you seek professional help as your obsession over these events is unhealthy On Fri, 8 Mar 2019 at 03:27, Luc Verhaegen wrote: > > On Fri, Mar 08, 2019 at 11:15:25AM +0900, Daniel Stone wrote: > > On Fri, 8 Mar 2019 at 10:52, Luc Verhaegen wrote: > > > A quick look over other > > > requests back then showed me that it usually took you many days, often > > > weeks, to answer new project requests. But when _i_ asked, a not too > > > supportive reply was quickly received. > > > > I've snipped most of the misleading accounts of history, incorrect or > > invented events, and pure outright defamatory lies that you've spent > > Defamation is a strong word, it means void of truth, void of data and > facts. > > Some googling will provide me with cover for those data points. I > also think i can dig out the email keithp sent us when he did create the > radeonhd repo, which will then also include the email that egbert sent > asking for project to at least you and keith. If needs be i will dig out > all the bugzilla entries with fd.o admin requests that you personally > responded to 6 months before and after (which will be laborious enough > already) i requested fd.o project resources for lima, and expose the > timeframes there (i will then also add Tollef's response times when i am > at it). And there's a whole bunch of former nokia guys on this ml, who > know just when you were thrown off the team and why, and how this was in > the september/october 2010 timeframe, shortly before you and ajax got > drunk and did what you did. > > > the last ten years posting all over the internet. There's no point in > > responding to them since you just go silent, then pop up six months or > > a year later to tell a new set of people the same old set of garbage, > > in the hope of destroying peoples' reputations and/or careers. > > > > I thought that after some pretty civil interactions recently, and > > Do you mean you coming to me in the fosdem devroom to convey that Eric > Faye-Lund would not be able to make it to talk at the devroom that day? > > Since you are a colleague of Eric, i had no reason to doubt your > statements. It would be foolish of me to assume that you were not > being truthful. Doing so would only hurt the graphics devroom and > FOSDEM, and it was paramount to inform fosdem visitors, and to then find > an alternative solution (which we did) to make maximum use of the > minimal time that the insane effort that is FOSDEM has. > > I never have and never will refuse a talk for the graphics devroom based > on how i like or dislike the person giving that talk. If i could bring > myself to doing that, i would invalidate any reason for my involvement > in the devroom and FOSDEM. FOSDEM and the graphics devroom come first. > > I will gladly ask nasty questions and will happily give you an earful, > especially at the delirium bar, as you well know. But i will not > brazenly affect the devroom schedule in such a way, let alone refuse > talks that are clear devroom material. > > > quickly and reasonably responding to your request for help with an > > explanation of why the mistake happened in the first place, that there > > was no danger here. But nope, after spending ten years tip-toeing > > around you, ignoring all the bait in the form of lies and defaming my > > character and motivations, but also trying to be 'fair' to the > > community by spending my time actioning your requests like the above, > > that's my reward. > > > > So here's my new and clear policy on Luc Verhaegen: I'm never in my > > life dealing with you again. If you ask for help or in fact any of my > > time, in any forum at all (e.g. here, sitewranglers@, IRC, whatever), > > I'm ignoring it. Even if I am literally the only person who can do the > > thing you ask for, whatever that is, I will flatly refuse to do it. If > > you file an issue which requires my action specifically, it will get > > immediately closed. > > You just communicated that you will now "officially" start doing exactly > what i claim that you have been doing for many years (amongst other > things). This as a response to me reiterating that very claim? How does > that work? > > On its own, this very statement precludes you from doing any custodial > work on any project. It also clearly displays that you feel that there > are tasks at freedesktop.org which can only be dealt with by yourself. > As if declaring that you will refuse to handle valid requests for > freedesktop.org resources, purely on the basis of interpersonal issues, > is not bad
Re: Radeonhd repo not migrated to gitlab.
On Fri, Mar 08, 2019 at 11:15:25AM +0900, Daniel Stone wrote: > On Fri, 8 Mar 2019 at 10:52, Luc Verhaegen wrote: > > A quick look over other > > requests back then showed me that it usually took you many days, often > > weeks, to answer new project requests. But when _i_ asked, a not too > > supportive reply was quickly received. > > I've snipped most of the misleading accounts of history, incorrect or > invented events, and pure outright defamatory lies that you've spent Defamation is a strong word, it means void of truth, void of data and facts. Some googling will provide me with cover for those data points. I also think i can dig out the email keithp sent us when he did create the radeonhd repo, which will then also include the email that egbert sent asking for project to at least you and keith. If needs be i will dig out all the bugzilla entries with fd.o admin requests that you personally responded to 6 months before and after (which will be laborious enough already) i requested fd.o project resources for lima, and expose the timeframes there (i will then also add Tollef's response times when i am at it). And there's a whole bunch of former nokia guys on this ml, who know just when you were thrown off the team and why, and how this was in the september/october 2010 timeframe, shortly before you and ajax got drunk and did what you did. > the last ten years posting all over the internet. There's no point in > responding to them since you just go silent, then pop up six months or > a year later to tell a new set of people the same old set of garbage, > in the hope of destroying peoples' reputations and/or careers. > > I thought that after some pretty civil interactions recently, and Do you mean you coming to me in the fosdem devroom to convey that Eric Faye-Lund would not be able to make it to talk at the devroom that day? Since you are a colleague of Eric, i had no reason to doubt your statements. It would be foolish of me to assume that you were not being truthful. Doing so would only hurt the graphics devroom and FOSDEM, and it was paramount to inform fosdem visitors, and to then find an alternative solution (which we did) to make maximum use of the minimal time that the insane effort that is FOSDEM has. I never have and never will refuse a talk for the graphics devroom based on how i like or dislike the person giving that talk. If i could bring myself to doing that, i would invalidate any reason for my involvement in the devroom and FOSDEM. FOSDEM and the graphics devroom come first. I will gladly ask nasty questions and will happily give you an earful, especially at the delirium bar, as you well know. But i will not brazenly affect the devroom schedule in such a way, let alone refuse talks that are clear devroom material. > quickly and reasonably responding to your request for help with an > explanation of why the mistake happened in the first place, that there > was no danger here. But nope, after spending ten years tip-toeing > around you, ignoring all the bait in the form of lies and defaming my > character and motivations, but also trying to be 'fair' to the > community by spending my time actioning your requests like the above, > that's my reward. > > So here's my new and clear policy on Luc Verhaegen: I'm never in my > life dealing with you again. If you ask for help or in fact any of my > time, in any forum at all (e.g. here, sitewranglers@, IRC, whatever), > I'm ignoring it. Even if I am literally the only person who can do the > thing you ask for, whatever that is, I will flatly refuse to do it. If > you file an issue which requires my action specifically, it will get > immediately closed. You just communicated that you will now "officially" start doing exactly what i claim that you have been doing for many years (amongst other things). This as a response to me reiterating that very claim? How does that work? On its own, this very statement precludes you from doing any custodial work on any project. It also clearly displays that you feel that there are tasks at freedesktop.org which can only be dealt with by yourself. As if declaring that you will refuse to handle valid requests for freedesktop.org resources, purely on the basis of interpersonal issues, is not bad enough already. > > Integrity is such a nice word. Somehow it feels like words like > > integrity and custodian belong together. > > Given all your vindictive and abusive bullying over many years, I > wouldn't if I were you choose 'personal and professional integrity' to > judge others on. Say what you will, but... I have never refused anyone mailing lists or other project resources. I have never silently removed anyone from planet.freedesktop.org. (1) I have never silently removed drivers from build scripts. I have never "lent" my root key to facilitate drunken hacking of repositories. I have never used root of a project hosting facility to vandalize projects. (2) And
Re: Radeonhd repo not migrated to gitlab.
On Fri, 8 Mar 2019 at 10:52, Luc Verhaegen wrote: > A quick look over other > requests back then showed me that it usually took you many days, often > weeks, to answer new project requests. But when _i_ asked, a not too > supportive reply was quickly received. I've snipped most of the misleading accounts of history, incorrect or invented events, and pure outright defamatory lies that you've spent the last ten years posting all over the internet. There's no point in responding to them since you just go silent, then pop up six months or a year later to tell a new set of people the same old set of garbage, in the hope of destroying peoples' reputations and/or careers. I thought that after some pretty civil interactions recently, and quickly and reasonably responding to your request for help with an explanation of why the mistake happened in the first place, that there was no danger here. But nope, after spending ten years tip-toeing around you, ignoring all the bait in the form of lies and defaming my character and motivations, but also trying to be 'fair' to the community by spending my time actioning your requests like the above, that's my reward. So here's my new and clear policy on Luc Verhaegen: I'm never in my life dealing with you again. If you ask for help or in fact any of my time, in any forum at all (e.g. here, sitewranglers@, IRC, whatever), I'm ignoring it. Even if I am literally the only person who can do the thing you ask for, whatever that is, I will flatly refuse to do it. If you file an issue which requires my action specifically, it will get immediately closed. > Integrity is such a nice word. Somehow it feels like words like > integrity and custodian belong together. Given all your vindictive and abusive bullying over many years, I wouldn't if I were you choose 'personal and professional integrity' to judge others on. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Fri, Mar 08, 2019 at 10:27:19AM +0900, Daniel Stone wrote: > On Fri, 8 Mar 2019 at 10:15, Luc Verhaegen wrote: > > On Fri, Mar 08, 2019 at 10:12:17AM +0900, Daniel Stone wrote: > > > I'll admit that somewhere between writing migration scripts, migrating > > > the other 1,268 repos from git.fd.o, maintaining our new and old > > > infrastructure, trying to find financial sponsorship for our > > > infrastructure, fire-fighting sudden 50% SMTP delivery failure rates, > > > bringing up a CI system and maintaining it as it exploded in use, > > > supporting people trying to use our new systems by walking them > > > through the API and bug-hunting for them, documenting and scripting > > > our new infrastructure so it can be replicated, dealing with regular > > > influxes of Bugzilla spam, trying to urgently move everyone off > > > Bugzilla as it's now abandoned upstream, helping Martin bring up the > > > new members.x.org so it's no longer an insanely insecure pile of PHP, > > > rewriting the fd.o homepage and lists of projects to not be massively > > > misleading, working on a lot on Wayland and Weston, working a bit on > > > Mesa/KMS/etc, then also doing my actual day job and taking care of my > > > personal life, I failed to make the time to specifically ensure that a > > > driver which has had one commit since 2010 was updated. > > > > It's just amazing how it is always the same repo and the same person > > that receives you and ajax special attention or more or less active lack > > thereof, depending on the situation. > > You're right that it is a special case. We only have 5 repos which > have a bare directory name (without the '.git' suffix): > xf86-video-radeonhd, cairo-5c (Nickle), pycairo and py2cairo (dormant > since 2012), and roadster (dormant since 2009), compared to 1,268 with > the suffix. Of those, xf86-video-radeonhd is the only one which got > migrated to GitLab, which I migrated as soon as it was brought to my > attention, after manually renaming the repository since the migration > scripts break if the git.fd.o repo does not have the suffix. > > I assume your next question is why it got quite uniquely created > without the suffix in the first place. For that, you'd have to ask the > person who created it: > drwxrwsr-x 8 eich xorg 4.0K Mar 7 21:31 xf86-video-radeonhd.git Keithp created it in september 2017. We asked you to do it when we happened to be outside of the XDC conference in cambridge in september 2007. We also asked you for a mailing list then, and you refused. Keith did this in the hours before we pushed code out, an event which, in itself, was already badly delayed by ATI not providing a valid open source license for us to include atombios code. Keith went and did the right thing to preserve the integrity of fd.o and added the repository. We ended up getting a mailing list created by our teamlead at SUSE, who got us a mailinglist at opensuse.org in the space of minutes, and that took us way less time than it took us to ask you and to listen to your excuses for not giving us a mailing list fd.o. You later went and bashed us for using a "corporate" mailing list. That was of course years before you went and tried to put the brakes on providing a mailing list for the lima driver. A quick look over other requests back then showed me that it usually took you many days, often weeks, to answer new project requests. But when _i_ asked, a not too supportive reply was quickly received. Amazingly, even jcristau felt the need to point out the duplicity of the answer to this request. All of this does not even begin to take into account the clear temporal correlation of the hacking of the radeonhd repository with you losing your consulting contract at nokia. Integrity is such a nice word. Somehow it feels like words like integrity and custodian belong together. Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Fri, 8 Mar 2019 at 10:15, Luc Verhaegen wrote: > On Fri, Mar 08, 2019 at 10:12:17AM +0900, Daniel Stone wrote: > > I'll admit that somewhere between writing migration scripts, migrating > > the other 1,268 repos from git.fd.o, maintaining our new and old > > infrastructure, trying to find financial sponsorship for our > > infrastructure, fire-fighting sudden 50% SMTP delivery failure rates, > > bringing up a CI system and maintaining it as it exploded in use, > > supporting people trying to use our new systems by walking them > > through the API and bug-hunting for them, documenting and scripting > > our new infrastructure so it can be replicated, dealing with regular > > influxes of Bugzilla spam, trying to urgently move everyone off > > Bugzilla as it's now abandoned upstream, helping Martin bring up the > > new members.x.org so it's no longer an insanely insecure pile of PHP, > > rewriting the fd.o homepage and lists of projects to not be massively > > misleading, working on a lot on Wayland and Weston, working a bit on > > Mesa/KMS/etc, then also doing my actual day job and taking care of my > > personal life, I failed to make the time to specifically ensure that a > > driver which has had one commit since 2010 was updated. > > It's just amazing how it is always the same repo and the same person > that receives you and ajax special attention or more or less active lack > thereof, depending on the situation. You're right that it is a special case. We only have 5 repos which have a bare directory name (without the '.git' suffix): xf86-video-radeonhd, cairo-5c (Nickle), pycairo and py2cairo (dormant since 2012), and roadster (dormant since 2009), compared to 1,268 with the suffix. Of those, xf86-video-radeonhd is the only one which got migrated to GitLab, which I migrated as soon as it was brought to my attention, after manually renaming the repository since the migration scripts break if the git.fd.o repo does not have the suffix. I assume your next question is why it got quite uniquely created without the suffix in the first place. For that, you'd have to ask the person who created it: drwxrwsr-x 8 eich xorg 4.0K Mar 7 21:31 xf86-video-radeonhd.git As always, it's been an absolute pleasure helping you, and sitting in my hotel room dealing with this has certainly been a much better use of my holiday time than enjoying Tokyo. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Fri, Mar 08, 2019 at 02:15:46AM +0100, Luc Verhaegen wrote: > On Fri, Mar 08, 2019 at 10:12:17AM +0900, Daniel Stone wrote: > > On Fri, 8 Mar 2019 at 09:52, Luc Verhaegen wrote: > > > On Fri, Mar 08, 2019 at 06:37:21AM +0900, Daniel Stone wrote: > > > > FWIW, It was unique amongst all Xorg repos in that it didn't have a > > > > .git suffix on the directory (i.e. its path was > > > > /srv/git.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/ rather > > > > than .../xf86-video-radeonhd.git/), which might explain it if you were > > > > pattern-matching to list all the repos. Certainly it broke the > > > > migration script so I had to rename it by hand first. Anyway, it's > > > > migrated now. > > > > > > And at no point in this process, or the past half a year or so, did you > > > look at that actual list above and notice anything, right? > > > > > > *sigh* > > > > I'll admit that somewhere between writing migration scripts, migrating > > the other 1,268 repos from git.fd.o, maintaining our new and old > > infrastructure, trying to find financial sponsorship for our > > infrastructure, fire-fighting sudden 50% SMTP delivery failure rates, > > bringing up a CI system and maintaining it as it exploded in use, > > supporting people trying to use our new systems by walking them > > through the API and bug-hunting for them, documenting and scripting > > our new infrastructure so it can be replicated, dealing with regular > > influxes of Bugzilla spam, trying to urgently move everyone off > > Bugzilla as it's now abandoned upstream, helping Martin bring up the > > new members.x.org so it's no longer an insanely insecure pile of PHP, > > rewriting the fd.o homepage and lists of projects to not be massively > > misleading, working on a lot on Wayland and Weston, working a bit on > > Mesa/KMS/etc, then also doing my actual day job and taking care of my > > personal life, I failed to make the time to specifically ensure that a > > driver which has had one commit since 2010 was updated. > > It's just amazing how it is always the same repo and the same person > that receives you and ajax special attention or more or less active lack > thereof, depending on the situation. You would think that people would, over time, learn to be especially careful to not so obviously run into such brazen issues, over and over again. Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Fri, Mar 08, 2019 at 10:12:17AM +0900, Daniel Stone wrote: > On Fri, 8 Mar 2019 at 09:52, Luc Verhaegen wrote: > > On Fri, Mar 08, 2019 at 06:37:21AM +0900, Daniel Stone wrote: > > > FWIW, It was unique amongst all Xorg repos in that it didn't have a > > > .git suffix on the directory (i.e. its path was > > > /srv/git.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/ rather > > > than .../xf86-video-radeonhd.git/), which might explain it if you were > > > pattern-matching to list all the repos. Certainly it broke the > > > migration script so I had to rename it by hand first. Anyway, it's > > > migrated now. > > > > And at no point in this process, or the past half a year or so, did you > > look at that actual list above and notice anything, right? > > > > *sigh* > > I'll admit that somewhere between writing migration scripts, migrating > the other 1,268 repos from git.fd.o, maintaining our new and old > infrastructure, trying to find financial sponsorship for our > infrastructure, fire-fighting sudden 50% SMTP delivery failure rates, > bringing up a CI system and maintaining it as it exploded in use, > supporting people trying to use our new systems by walking them > through the API and bug-hunting for them, documenting and scripting > our new infrastructure so it can be replicated, dealing with regular > influxes of Bugzilla spam, trying to urgently move everyone off > Bugzilla as it's now abandoned upstream, helping Martin bring up the > new members.x.org so it's no longer an insanely insecure pile of PHP, > rewriting the fd.o homepage and lists of projects to not be massively > misleading, working on a lot on Wayland and Weston, working a bit on > Mesa/KMS/etc, then also doing my actual day job and taking care of my > personal life, I failed to make the time to specifically ensure that a > driver which has had one commit since 2010 was updated. It's just amazing how it is always the same repo and the same person that receives you and ajax special attention or more or less active lack thereof, depending on the situation. Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Fri, 8 Mar 2019 at 09:52, Luc Verhaegen wrote: > On Fri, Mar 08, 2019 at 06:37:21AM +0900, Daniel Stone wrote: > > FWIW, It was unique amongst all Xorg repos in that it didn't have a > > .git suffix on the directory (i.e. its path was > > /srv/git.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/ rather > > than .../xf86-video-radeonhd.git/), which might explain it if you were > > pattern-matching to list all the repos. Certainly it broke the > > migration script so I had to rename it by hand first. Anyway, it's > > migrated now. > > And at no point in this process, or the past half a year or so, did you > look at that actual list above and notice anything, right? > > *sigh* I'll admit that somewhere between writing migration scripts, migrating the other 1,268 repos from git.fd.o, maintaining our new and old infrastructure, trying to find financial sponsorship for our infrastructure, fire-fighting sudden 50% SMTP delivery failure rates, bringing up a CI system and maintaining it as it exploded in use, supporting people trying to use our new systems by walking them through the API and bug-hunting for them, documenting and scripting our new infrastructure so it can be replicated, dealing with regular influxes of Bugzilla spam, trying to urgently move everyone off Bugzilla as it's now abandoned upstream, helping Martin bring up the new members.x.org so it's no longer an insanely insecure pile of PHP, rewriting the fd.o homepage and lists of projects to not be massively misleading, working on a lot on Wayland and Weston, working a bit on Mesa/KMS/etc, then also doing my actual day job and taking care of my personal life, I failed to make the time to specifically ensure that a driver which has had one commit since 2010 was updated. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Fri, Mar 08, 2019 at 06:37:21AM +0900, Daniel Stone wrote: > On Fri, 8 Mar 2019 at 04:35, Adam Jackson wrote: > > On Wed, 2019-03-06 at 17:04 +0100, Luc Verhaegen wrote: > > > Is there a reason why, of _all_ drivers listed in > > > > > > https://cgit.freedesktop.org/xorg/driver > > > > > > the Radeonhd repository at > > > > > > https://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/ > > > > > > has not been mirrored? > > > > Pretty sure I came up with the list of modules to migrate from the set > > I happened to have cloned locally, but it's been months. I've added a > > note to the migration ticket: > > > > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 > > ... and I've migrated it. > > FWIW, It was unique amongst all Xorg repos in that it didn't have a > .git suffix on the directory (i.e. its path was > /srv/git.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/ rather > than .../xf86-video-radeonhd.git/), which might explain it if you were > pattern-matching to list all the repos. Certainly it broke the > migration script so I had to rename it by hand first. Anyway, it's > migrated now. And at no point in this process, or the past half a year or so, did you look at that actual list above and notice anything, right? *sigh* Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Fri, 8 Mar 2019 at 04:35, Adam Jackson wrote: > On Wed, 2019-03-06 at 17:04 +0100, Luc Verhaegen wrote: > > Is there a reason why, of _all_ drivers listed in > > > > https://cgit.freedesktop.org/xorg/driver > > > > the Radeonhd repository at > > > > https://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/ > > > > has not been mirrored? > > Pretty sure I came up with the list of modules to migrate from the set > I happened to have cloned locally, but it's been months. I've added a > note to the migration ticket: > > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 ... and I've migrated it. FWIW, It was unique amongst all Xorg repos in that it didn't have a .git suffix on the directory (i.e. its path was /srv/git.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/ rather than .../xf86-video-radeonhd.git/), which might explain it if you were pattern-matching to list all the repos. Certainly it broke the migration script so I had to rename it by hand first. Anyway, it's migrated now. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Wed, 2019-03-06 at 17:04 +0100, Luc Verhaegen wrote: > Is there a reason why, of _all_ drivers listed in > > https://cgit.freedesktop.org/xorg/driver > > the Radeonhd repository at > > https://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/ > > has not been mirrored? Pretty sure I came up with the list of modules to migrate from the set I happened to have cloned locally, but it's been months. I've added a note to the migration ticket: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Radeonhd repo not migrated to gitlab.
Is there a reason why, of _all_ drivers listed in https://cgit.freedesktop.org/xorg/driver the Radeonhd repository at https://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/ has not been mirrored? Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
