+1
I think it is a good idea to keep the spec doc and api together for
versioning
Ivar
On Tue, Mar 1, 2016 at 10:48 AM arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> Okay, I'm convinced ;) Let's drop the uber repo idea.
>
> Coherent naming conventions would still be a good idea I guess. E.g.
>
> https://github.com/[SPEC-NAME]-spec
> /[SPEC-NAME]-proposals
> /[SPEC-NAME]-examples
> /[SPEC-NAME]-API
> /[RI-NAME]
>
> What about a separate repo for the spec document, or put it in
> /[SPEC-NAME]-API?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
> On Tue, Mar 1, 2016 at 10:04 AM, Werner Keil <werner.keil_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> My "50 cent" from running or helping a few rather succesful JSRs like 354
>> or 363 on GitHub.
>> The one orga per JSR strategy sounds better. GitHub has a very distinct
>> and good memory. Every PR you merge makes the person who raised it a
>> "contributor" to that codebase. Before JSR 364/EC even made sure, that type
>> of member even exists (it should be when 364 goes final) Thus in a "Uber
>> orga" for all of Java EE it would be much harder to follow who is in what
>> EG and who isn't if there are PRs.
>>
>> Werner
>>
>> On Tue, Mar 1, 2016 at 7:55 AM, Ivar Grimstad <ivar.grimstad_at_gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I agree. The limitation in GitHub that only allows for one github pages
>>> site per org/account also favors separate orgs.
>>>
>>> Regarding migrate the spec from word to asciidoc, what if we set up the
>>> structure at JavaLand next week and start to migrate section for section.
>>> The we can encourage the community to help by converting a part and sending
>>> PRs? Just a thought... there's a *lot* of pages...
>>>
>>> Ivar
>>>
>>>
>>> On Mon, Feb 29, 2016 at 11:51 PM David Blevins <dblevins_at_tomitribe.com>
>>> wrote:
>>>
>>>> Hello from an airport!
>>>>
>>>> Chiming in to show support for the proposal. In reference to one big
>>>> org for all of EE, I'd be in favor of separate orgs to
>>>>
>>>> 1) give spec leads the most control. Aggregating control/authority to
>>>> a center usually slows things down.
>>>>
>>>> 2) more closely matches current java.net org for easier migration
>>>>
>>>> That said there still could be a javaee repo with forks of the other
>>>> repos. Though perhaps not worth the overhead.
>>>>
>>>> The other item that would be great to see is converting the word spec
>>>> to asciidoc using the same setup as CDI
>>>>
>>>> -David
>>>>
>>>> On Monday, February 29, 2016, Ivar Grimstad <ivar.grimstad_at_gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> What do you think of using this unfortunate "quiet period" to move
>>>>> from Subversion to Git?
>>>>>
>>>>> The way the java.net svn repo is organized does not allow for easy
>>>>> migration to Git, but here is a suggestion that should be feasible:
>>>>>
>>>>> - Migrate the jms2.1 folder to a new Git repository as the master
>>>>> branch.
>>>>> - Migrate the www folder to a new Git repository (separate from
>>>>> the above)
>>>>> - Keep the rest in the Subversion repo as is
>>>>>
>>>>> Why GitHub and not java.net?
>>>>>
>>>>> - GitHub offers better support for collaboration and pull requests
>>>>> - I don't have access to create repositories on java.net
>>>>> - The future of java.net is uncertain (rumor has it...)
>>>>> - When and if we have a java.net Git repo, we can move everything
>>>>> there, treat as master and use the GitHub repo as a mirror.
>>>>>
>>>>> Any objections? Or suggestions otherwise?
>>>>> I will be happy to fix this and for the purpose I have created a
>>>>> GitHub group/organization:
>>>>> (we have done the same thing with JSR 371 and JSR 375)
>>>>>
>>>>> https://github.com/jms-spec
>>>>>
>>>>> I will add all of you to this group if I can find your github user.
>>>>> Please email me your username if you don't get an invitation.
>>>>>
>>>>> Ivar
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from Gmail Mobile
>>>>
>>>
>>
>