[U-Boot-Custodians] git access - move to gitlab?

Michal Simek monstr at monstr.eu
Mon Mar 25 15:28:02 UTC 2019


On 25. 03. 19 16:19, Tom Rini wrote:
> On Mon, Mar 25, 2019 at 03:05:10PM +0100, Michal Simek wrote:
>> On 25. 03. 19 13:56, Tom Rini wrote:
>>> On Mon, Mar 25, 2019 at 01:35:05PM +0100, Wolfgang Denk wrote:
>>>> Hi all,
>>>>
>>>> I guess a few of you will have noticed the recent issues with
>>>> HTTP(S) access to the custodian repositories; recent versions of git
>>>> have introduced changes which are incompatible with the way how
>>>> "alternates" and "http-alternates" have been working for many years.
>>>>
>>>> For a quick fix, I have now repacked all the repositories and
>>>> removed the alternates / http-alternates files, so cloning over
>>>> HTTP(S) should be working again.
>>>>
>>>> However, I think this is just a quick fix, and not a long term
>>>> solution.  The git.denx.de server itself is a bit oldish, and the
>>>> gitweb setup running on git.denx.de is old and ugly and limited and
>>>> slow...
>>>>
>>>> I would like to move all the custodian repos to our gitlab server.
>>>> This is a more powerfull machine, and we would have a number of
>>>> additional options there.  We can still provide "classic" git
>>>> protocol access even under the old URLs.
>>>>
>>>> Are there any concerns about this?
>>>>
>>>> When would be a good point in time (in release schedule) for such a
>>>> move?
>>>>
>>>> Do we have to migrate all repositories at once, or can we have a few
>>>> "early adaptors" who serve as guinea pigs?
>>>
>>> The only concern I have is can we rewrite links like
>>> https://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/howto.txt;h=8592719685eba10f72886e04b0b1ad9f91b3c61e;hb=HEAD
>>> so they get redirected?  There's a lot of stuff like that floating
>>> around that I'd like to have still be valid.  Thanks again!
>>
>> If you look at current custodian workflow then at least I push branch to
>> github to be taken by travis to build and test there.
>> Then I am pushing it to denx.de and sending pull request with signed tags.
>>
>> Is there a support for travis in gitlab?
>> If not, I tend to say that maybe it is time to also send pull request
>> from others repos out of denx.de.
>> But definitely it is nice to have all these repos in the same location
>> to also check what others are doing.
> 
> Travis-CI is unfortunately github-centric.  gitlab has its own CI stuff
> which my first hesitation on is "do we really want to start melting some
> DENX dev machines?" because the big selling feature on using travis is,
> even if it's slow and network fails way more often than I'd like, it's
> free, unlike doing builds on AWS/Google Compute/Azure.  One thing I have
> looked into a little bit is that sr.ht doesn't yet, but plans to, allow
> for using your own build HW with whatever time/threading restrictions
> you want to allow on it.
> 
> That, or figuring out how to use gitlab's CI with specify a build
> machine/cluster might be a further improvement.
> 

I am not fan github at all for various reasons but if there is no value
to move custodian trees to gitlab then why this should be done?

I am not quite sure if there is any existing restriction that pull
request should be just from repos at current git server but if people
want to move gitlab then they should move. If people want to use just
github or whatever else they could use that too and sending PR from that
locations.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot-custodians/attachments/20190325/78fdffa7/attachment.sig>


More information about the U-Boot-Custodians mailing list