llvm dev - Jun 2016 - [cfe-dev] Git Move: GitHub+modules proposal

On 30 June 2016 at 05:14, Tim Northover <t.p.northover at gmail.com>
wrote:
>> That makes it fragile, and that’s why I disagree with your “90% done”
assessment.
>> What if the service behing the hook is down for a few days?
>
> In the long-term view, a pretty trivial catch-up script ought to be
> able to synthesize a sane history after any amount of down-time.
> People could even run it locally for their bisecting needs if it was
> that important to them.
Yup. If the script is stable (as in sort stable), anyone running it
locally will get the same results as upstream and each other.

> In the short term, I don't think it's a critical enough service to
> worry about, frankly. What we already have is hopelessly fragile:
> right now when LLVM's server plays up it takes out absolutely
> everything, in the proposed world it would take out this bisecting
> convenience feature. Seems like a strict improvement to me.
I think it's even less important than that. Bisecting will work
*better* when using submodules than it does using SVN (because git
bisect is more powerful, allows me to track all modules' history, and
will rid me of a complicated downstream set of SVN-bisect scripts).

The only thing we *have* to have a sequential number for, are
releases. Even that can be ran manually.

We agreed to have sequential numbering from the start to allow
infrastructure to migrate slowly to a Git model. That can also have an
extra step to run the script if IDs are not populated yet.

>> Who will maintain it?
Whoever maintains the current infrastructure, which is currently the
Foundation. All scripts will be upstream.

So far, they (Tanya, Anton, Galina) have been very responsible to
every downtime and problems I found. I have no doubt that this will
continue to be a trend.

cheers,
--renato

> On Jun 30, 2016, at 1:26 AM, Renato Golin via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 
> On 30 June 2016 at 05:14, Tim Northover <t.p.northover at gmail.com>
wrote:
>>> That makes it fragile, and that’s why I disagree with your “90%
done” assessment.
>>> What if the service behing the hook is down for a few days?
>> 
>> In the long-term view, a pretty trivial catch-up script ought to be
>> able to synthesize a sane history after any amount of down-time.
>> People could even run it locally for their bisecting needs if it was
>> that important to them.
> 
> Yup. If the script is stable (as in sort stable), anyone running it
> locally will get the same results as upstream and each other.
> 
> 
>> In the short term, I don't think it's a critical enough service
to
>> worry about, frankly. What we already have is hopelessly fragile:
>> right now when LLVM's server plays up it takes out absolutely
>> everything, in the proposed world it would take out this bisecting
>> convenience feature. Seems like a strict improvement to me.
> 
> I think it's even less important than that. Bisecting will work
> *better* when using submodules than it does using SVN (because git
> bisect is more powerful, allows me to track all modules' history, and
> will rid me of a complicated downstream set of SVN-bisect scripts).
> 
> The only thing we *have* to have a sequential number for, are
> releases. Even that can be ran manually.
LNT and ‘llvmlab bisect’ also currently rely heavily on having sequential
numbers as commit identifiers.

Fred 
> We agreed to have sequential numbering from the start to allow
> infrastructure to migrate slowly to a Git model. That can also have an
> extra step to run the script if IDs are not populated yet.
> 
> 
>>> Who will maintain it?
> 
> Whoever maintains the current infrastructure, which is currently the
> Foundation. All scripts will be upstream.
> 
> So far, they (Tanya, Anton, Galina) have been very responsible to
> every downtime and problems I found. I have no doubt that this will
> continue to be a trend.
> 
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On 30 June 2016 at 16:23, Frédéric Riss <friss at apple.com>
wrote:
>> The only thing we *have* to have a sequential number for, are
>> releases. Even that can be ran manually.
>
> LNT and ‘llvmlab bisect’ also currently rely heavily on having sequential
numbers as commit identifiers.
One of the steps of the migration is to re-write the infrastructure to
use Git's history instead of sequential numbers.

LLVM Lab bisect is probably easier than LNT, but as I said, this is
*only* a problem when the service goes down, which shouldn't be common
at all.

cheers,
--renato