Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Xinliang David Li via lldb-dev]

On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth 
wrote:

> On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> I also believe this is the simplest versioning scheme*. It eliminates all
>> future debates on this topic (e.g, when to bump major version etc) and
>> solves the problem once and for all --  which is another plus :)
>>
>
> Except that we'll have to keep dealing with people who are confused why we
> have two version numbers but they don't mean anything. That's why I think
> if we don't want major/minor going forward, we should remove the '.'
> regardless of what number we pick.
>

I am not sure what the confusion is actually. We can apply the following
test to see if the versioning scheme is simple/non-confusing or not: 1) for
release managers: given the current version, what is the next version going
to be? If it is predictable and not requiring lots of effort like this to
debate, then it is a good scheme (IMO); 2) for compiler/tool users: given
the current version, can I easily find out what the previous version is?
what is the version N releases ahead? If it requires googling, then it is
not a good scheme.

David



>
>>
>> *) similar suggestions a) start from 4, increase by 1; b) start from 40,
>> increase by 1.   Date based scheme is also a variant of it.
>>
>> David
>>
>>
>> On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev <
>> cfe-...@lists.llvm.org> wrote:
>>
>>> I also support Chris's position of 4.0, 4.1 etc. I don't think
>>> "majorness" is that important, and we can sort out the bit code
>>> compatibility story some other way.
>>>
>>> Sent from phone
>>> On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
>>> llvm-...@lists.llvm.org> wrote:
>>>
 On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg 
 wrote:
 > Breaking this out into a separate thread since it's kind of a separate
 > issue, and to make sure people see it.
 >
 > If you have opinions on this, please chime in. I'd like to collect as
 > many arguments here as possible to make a good decision. The main
 > contestants are 4.0 and 3.10, and I've seen folks being equally
 > surprised by both.

 Thanks everyone for chiming in.

 Please correct me if I misrepresent your opinion here, but I need to
 try and summarize this thread for my own sanity:

 The thread started out with lots of support for 3.10, the reasoning
 being roughly that we shouldn't bump the major version number unless
 we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
 Chandler, Anton, Eric, Aaron, Sean, Vikram).

 Richard suggested that since we do time-based rather than
 feature-based releases, the distinction between a release with or
 without major changes is arbitrary, and we should move to a scheme
 where we update the major version number on each release (4.0, 5.0,
 etc.) with minor releases in between (4.1, 5.1, ..).

 Chris advocated for "keep adding 0.1 to each major release" (in the
 decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
 suggest this. "I do not think it is reasonable at all to go to '3.10'
 after '3.9', because we will never get to '4.0'."

 Chris then expressed support for alternatively just incrementing the
 major version each time, as Richard suggested, but starting at 40.

 Rafael expressed support for the above, but starting at 4.0: "It is
 simply not worth the time to try to figure out what is 'major' in a
 project with so many different uses."

 Chandler said he didn't like Chris's "keep adding 0.1 to each major
 release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some
 decimal correspondence", and said he was open to either going to 3.10
 with the current major/minor split, or if we don't want that, use
 Richard's suggestion.

 Michael pointed out that if we do change the numbering scheme,
 changing the binary compatibility guarantee to something time-based
 isn't equivalent to what we currently have.



 So, it seems we're at an impasse with several folks in favour of 3.10,
 Chris speaking out strongly against it, and Richard's option which has
 some traction and which no one's disagreed with so far, but which
 would be a bigger change.

 I'll have a think about this over the weekend.

 Cheers,
 Hans
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

>>>
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> 

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 26 June 2016 at 23:02, Anton Korobeynikov  wrote:
> Does github allow this? IIRC their support for server-side hooks was
> very limited due to obvious reasons. And executing hooks e.g. on
> llvm.org seems very error-prone.

Someone suggested it was possible. I have sent them an email with a
draft proposal and they said everything was fine, though they didn't
confirm specific support.

I can't see shy changing a local auto-increment ID on the repository
itself would be a breach of security, so even if there are
limitations, I think we can get this done.

I'll send them another email to confirm this specific point.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Anton Korobeynikov via lldb-dev]

>  1. Control the history via server hooks updating a unique and
> auto-increment identifier, which will apply to every commit on its
> submodules (ie, every other LLVM project).
Does github allow this? IIRC their support for server-side hooks was
very limited due to obvious reasons. And executing hooks e.g. on
llvm.org seems very error-prone.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

So,

It's been a while and the GitHub thread is officially dead, so I'll
propose a development methodology based on the feedback from that
thread. This is not *my* view, but all that was discussed in the
threads.

My objective is to form an official proposal to use Git as our main
repository, overcoming all the problems we currently have without
creating many others. In the end, I think Tanya wanted to make a vote,
and see how string the community feels about it. The vote should be
"Should we move to GitHub as the proposed workflow, or should we try
to find another solution away from our own hosting?".

The important part is that we *must* move from the current schema. It
does not scale and the administrative costs are not worth the trouble.
So, if we don't go with GitHub, we have to find another way out.

The proposal
==

Move to GitHub with N+1 projects: all current LLVM projects + the
"llvm-projs" umbrella. The latter will have all other projects as
"submodules" with the intent to:

 1. Control the history via server hooks updating a unique and
auto-increment identifier, which will apply to every commit on its
submodules (ie, every other LLVM project).
 2. Serve as a reference for releases, buildbots, etc., checking out
only the necessary submodules for each.
 3. Have additional logic to handle the additional complexity for
mailing lists, tools, buildbots to deal with the umbrella project
*only*.

The existing LLVM projects (llvm, clang, compiler-rt, etc) will
continue on their own repositories and be built locally just like they
are today. You can check them out individually inside the final
directory (llvm/tools/clang) or use symbolic links, just like we do
today. You can also checkout "llvm-projs" and update only the required
submodules, and use symbolic links.

The llvm-projs umbrella will have its own versioning, and tools can
report that ID as their "version", if they're not in a release branch.

Release branches should be off of master and have a linear history,
just like master, in the exact same way we do now with SVN. This will
guarantee the umbrella project will be able to correctly
auto-increment the ID and make sure current tools work as usual.

We don't want private branches to end up in upstream LLVM (only
upstream release branches), but that's perfectly natural in GitHub,
where anyone can fork and implement their features and own releases
off of the upstream official repositories.

This can work as well for upstream development of "feature branches",
where upstream developers contribute to both repositories, but keeping
a specific feature in test separate. Merges will still have to be like
it is today, one patch at a time, or risk reverting the whole merge
window if the buildbots start breaking, which can be impossible if the
window is large or two or more windows get committed at the same time.

For "feature branches" we could use git-imerge, but that's for the
future and not considered in the first stage of the move.

Git Submodules
-

There were concerns is submodules would work with our flow, but the
concerns were addressed by demonstrating that:

 1. Submodules can work in an umbrella project, which controls the
auto-increment ID
 2. You can check-out individual modules or all, so work well for
releases and buildbots
 3. The history is shared with the root project, so git-bisect works
out of the box

The Alternatives
-

A few alternatives were proposed, but git submodules ended up being
considered more thoroughly. Here are some of the reasons:

 * Google repo:

It's an independent tool, which may suite us today, but not
necessarily tomorrow. It may work well with the infrastructure that is
already set for it on other projects (mostly Google projects like
Android), but it does require some tooling (like git submodules). The
point is, that it's much more likely to exist tooling for official git
features than third-party projects, especially on Windows.

 * All-in-one:

Proposals to have all projects inside one big repo were quickly
dismissed due to the problems it creates to *users* of LLVM as a
library, and to build systems (specific buildbots) that don't need to
monitor all changes all the time. It simply won't scale.

 * Multiple clones:

Allowing the projects to *exist* in different conditions (clang inside
LLVM, or as a stand-alone library) will not scale. CMake will have to
cope with all the different styles, it doesn't solve the unique
auto-increment ID nor it helps downstream projects migrate to a common
infrastructure.

Questions


In order to make this proposal final, I still need a few questions to
be answered.

1. How will the umbrella project's auto-increment hook work?

Will it be one ID for every commit in every other repo? How will it
know which one came first? Does it matter? If we have two commit "at
the same time", do we create a priority list?

Ex. LLVM commits get a lower ID than Clang ones, because it's 

Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> I also believe this is the simplest versioning scheme*. It eliminates all
> future debates on this topic (e.g, when to bump major version etc) and
> solves the problem once and for all --  which is another plus :)
>

Except that we'll have to keep dealing with people who are confused why we
have two version numbers but they don't mean anything. That's why I think
if we don't want major/minor going forward, we should remove the '.'
regardless of what number we pick.


>
> *) similar suggestions a) start from 4, increase by 1; b) start from 40,
> increase by 1.   Date based scheme is also a variant of it.
>
> David
>
>
> On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> I also support Chris's position of 4.0, 4.1 etc. I don't think
>> "majorness" is that important, and we can sort out the bit code
>> compatibility story some other way.
>>
>> Sent from phone
>> On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
>> llvm-...@lists.llvm.org> wrote:
>>
>>> On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg 
>>> wrote:
>>> > Breaking this out into a separate thread since it's kind of a separate
>>> > issue, and to make sure people see it.
>>> >
>>> > If you have opinions on this, please chime in. I'd like to collect as
>>> > many arguments here as possible to make a good decision. The main
>>> > contestants are 4.0 and 3.10, and I've seen folks being equally
>>> > surprised by both.
>>>
>>> Thanks everyone for chiming in.
>>>
>>> Please correct me if I misrepresent your opinion here, but I need to
>>> try and summarize this thread for my own sanity:
>>>
>>> The thread started out with lots of support for 3.10, the reasoning
>>> being roughly that we shouldn't bump the major version number unless
>>> we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
>>> Chandler, Anton, Eric, Aaron, Sean, Vikram).
>>>
>>> Richard suggested that since we do time-based rather than
>>> feature-based releases, the distinction between a release with or
>>> without major changes is arbitrary, and we should move to a scheme
>>> where we update the major version number on each release (4.0, 5.0,
>>> etc.) with minor releases in between (4.1, 5.1, ..).
>>>
>>> Chris advocated for "keep adding 0.1 to each major release" (in the
>>> decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
>>> suggest this. "I do not think it is reasonable at all to go to '3.10'
>>> after '3.9', because we will never get to '4.0'."
>>>
>>> Chris then expressed support for alternatively just incrementing the
>>> major version each time, as Richard suggested, but starting at 40.
>>>
>>> Rafael expressed support for the above, but starting at 4.0: "It is
>>> simply not worth the time to try to figure out what is 'major' in a
>>> project with so many different uses."
>>>
>>> Chandler said he didn't like Chris's "keep adding 0.1 to each major
>>> release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some
>>> decimal correspondence", and said he was open to either going to 3.10
>>> with the current major/minor split, or if we don't want that, use
>>> Richard's suggestion.
>>>
>>> Michael pointed out that if we do change the numbering scheme,
>>> changing the binary compatibility guarantee to something time-based
>>> isn't equivalent to what we currently have.
>>>
>>>
>>>
>>> So, it seems we're at an impasse with several folks in favour of 3.10,
>>> Chris speaking out strongly against it, and Richard's option which has
>>> some traction and which no one's disagreed with so far, but which
>>> would be a bigger change.
>>>
>>> I'll have a think about this over the weekend.
>>>
>>> Cheers,
>>> Hans
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev