Postponing the July Meeting

[Colin Finck]

Hi all!

Looking at the calendar, it would be time for the July Meeting today.
However, I didn't receive any agenda proposals and also forgot to
announce it in the course of releasing 0.4.9.
So I suggest we postpone the meeting to next week's Thursday, August 2.

Please send agenda proposals by then.
That meeting also allows us to handle last-minute planning regarding the
Hackfest.

Best regards,

Colin

[Ged Murphy]

I have an item for the agenda. I'd like to discuss the possibility of moving some of our drivers out of the main repo and into something more convenient.

In case I don't make the meeting, I'll put forward some of my reasons here:

This thought has come about due to the btrfs driver which we use from Mark Harmstone. Mark's project receives quite a bit of interest on github, and I'm assuming one of the reasons is that it's so easy to find and build. Searching for 'btrfs windows' lists his project as the top hit in google, and building is as simple as cloning, opening the project in VS and clicking build (assuming you have the WDK)

I'm wondering if we did the same thing to some of our drivers, we might generate more interest in them. A good example would be our NTFS driver. When searching for open source NTFS solutions you're only really given Linux and Max options. The reactos driver is buried deep in the search list, and you only see it if you know what you're looking for. Next if you want to build it, you need to clone the main reactos repo, install the build tools, setup and build the environment, build the tool chain, build the linkers libs, etc, etc. There are so many barriers for people who aren't part of the reactos development team that the chance of getting anyone interested in it are practically zero.

This process would be much simpler if the code was available to clone as a separate project, and could simply build with the WDK and VS. There's then a chance that it might start to generate interest, and people may start working on it instead of it just bit-rotting deep in our main repo.

If we're going to do that, why not consider others too. Network cards, sound stack, USB, boot loaders, printer drivers, directx, etc, There's lots of things that people might be interested in working on and using if they weren't tied to the reactos code base. We obviously benefit from any external interest, and simply pull/import it back into the reactos project.

Ged.

-----Original Message-----
From: Ros-dev [e-mail] On Behalf Of Colin Finck
Sent: Thursday, 26 July 2018 17:58
To: 'ReactOS Development List' [e-mail]
Subject: [ros-dev] Postponing the July Meeting

Hi all!

Looking at the calendar, it would be time for the July Meeting today.
However, I didn't receive any agenda proposals and also forgot to announce it in the course of releasing 0.4.9.
So I suggest we postpone the meeting to next week's Thursday, August 2.

Please send agenda proposals by then.
That meeting also allows us to handle last-minute planning regarding the Hackfest.

Best regards,

Colin

[Hermès BÉLUSCA-MAÏTO]

Hi,

This sounds interesting, for potential developers wanting just to work on some module, but not wanting to deal with the whole OS thing.
Would this mean that we also have to think about git submodules? Because (in the case of the NTFS driver for example) it would be in a different git repo, and then it would have to be automatically downloaded and updated whenever one of the core ROS dev updates his own ROS git repo.

Cheers,
Hermes
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]] De la part de Ged Murphy
> Envoyé : mercredi 1 août 2018 20:16
> À : 'ReactOS Development List'
> Objet : Re: [ros-dev] Postponing the July Meeting
>
> I have an item for the agenda. I'd like to discuss the possibility of moving some
> of our drivers out of the main repo and into something more convenient.
>
> In case I don't make the meeting, I'll put forward some of my reasons here:
>
> This thought has come about due to the btrfs driver which we use from Mark
> Harmstone. Mark's project receives quite a bit of interest on github, and I'm
> assuming one of the reasons is that it's so easy to find and build. Searching for
> 'btrfs windows' lists his project as the top hit in google, and building is as simple
> as cloning, opening the project in VS and clicking build (assuming you have the
> WDK)
>
> I'm wondering if we did the same thing to some of our drivers, we might
> generate more interest in them. A good example would be our NTFS driver.
> When searching for open source NTFS solutions you're only really given Linux
> and Max options. The reactos driver is buried deep in the search list, and you
> only see it if you know what you're looking for. Next if you want to build it, you
> need to clone the main reactos repo, install the build tools, setup and build the
> environment, build the tool chain, build the linkers libs, etc, etc. There are so
> many barriers for people who aren't part of the reactos development team that
> the chance of getting anyone interested in it are practically zero.
>
> This process would be much simpler if the code was available to clone as a
> separate project, and could simply build with the WDK and VS. There's then a
> chance that it might start to generate interest, and people may start working
> on it instead of it just bit-rotting deep in our main repo.
>
> If we're going to do that, why not consider others too. Network cards, sound
> stack, USB, boot loaders, printer drivers, directx, etc, There's lots of things that
> people might be interested in working on and using if they weren't tied to the
> reactos code base. We obviously benefit from any external interest, and simply
> pull/import it back into the reactos project.
>
> Ged.
>
> -----Original Message-----
> From: Ros-dev [e-mail] On Behalf Of Colin Finck
> Sent: Thursday, 26 July 2018 17:58
> To: 'ReactOS Development List' [e-mail]
> Subject: [ros-dev] Postponing the July Meeting
>
> Hi all!
>
> Looking at the calendar, it would be time for the July Meeting today.
> However, I didn't receive any agenda proposals and also forgot to announce it
> in the course of releasing 0.4.9.
> So I suggest we postpone the meeting to next week's Thursday, August 2.
>
> Please send agenda proposals by then.
> That meeting also allows us to handle last-minute planning regarding the
> Hackfest.
>
> Best regards,
>
> Colin
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[David Quintana (gigaherz)]

I would suggest against using submodules, but we can discus that in the
meeting, if you want. There's alternatives.

On Wed, 1 Aug 2018 at 21:21, Hermès BÉLUSCA-MAÏTO [e-mail]
wrote:
> Hi,
>
> This sounds interesting, for potential developers wanting just to work on
> some module, but not wanting to deal with the whole OS thing.
> Would this mean that we also have to think about git submodules? Because
> (in the case of the NTFS driver for example) it would be in a different git
> repo, and then it would have to be automatically downloaded and updated
> whenever one of the core ROS dev updates his own ROS git repo.
>
> Cheers,
> Hermes
> > -----Message d'origine-----
> > De : Ros-dev [mailto:[e-mail]] De la part de Ged
>
> Murphy
> > Envoyé : mercredi 1 août 2018 20:16
> > À : 'ReactOS Development List'
> > Objet : Re: [ros-dev] Postponing the July Meeting
> >
> > I have an item for the agenda. I'd like to discuss the possibility of
>
> moving some
> > of our drivers out of the main repo and into something more convenient.
> >
> > In case I don't make the meeting, I'll put forward some of my reasons
>
> here:
> > This thought has come about due to the btrfs driver which we use from
>
> Mark
> > Harmstone. Mark's project receives quite a bit of interest on github,
>
> and I'm
> > assuming one of the reasons is that it's so easy to find and build.
>
> Searching for
> > 'btrfs windows' lists his project as the top hit in google, and building
>
> is as simple
> > as cloning, opening the project in VS and clicking build (assuming you
>
> have the
> > WDK)
> >
> > I'm wondering if we did the same thing to some of our drivers, we might
> > generate more interest in them. A good example would be our NTFS driver.
> > When searching for open source NTFS solutions you're only really given
>
> Linux
> > and Max options. The reactos driver is buried deep in the search list,
>
> and you
> > only see it if you know what you're looking for. Next if you want to
>
> build it, you
> > need to clone the main reactos repo, install the build tools, setup and
>
> build the
> > environment, build the tool chain, build the linkers libs, etc, etc.
>
> There are so
> > many barriers for people who aren't part of the reactos development team
>
> that
> > the chance of getting anyone interested in it are practically zero.
> >
> > This process would be much simpler if the code was available to clone as
>
> a
> > separate project, and could simply build with the WDK and VS. There's
>
> then a
> > chance that it might start to generate interest, and people may start
>
> working
> > on it instead of it just bit-rotting deep in our main repo.
> >
> > If we're going to do that, why not consider others too. Network cards,
>
> sound
> > stack, USB, boot loaders, printer drivers, directx, etc, There's lots of
>
> things that
> > people might be interested in working on and using if they weren't tied
>
> to the
> > reactos code base. We obviously benefit from any external interest, and
>
> simply
> > pull/import it back into the reactos project.
> >
> > Ged.
> >
> > -----Original Message-----
> > From: Ros-dev [e-mail] On Behalf Of Colin Finck
> > Sent: Thursday, 26 July 2018 17:58
> > To: 'ReactOS Development List' [e-mail]
> > Subject: [ros-dev] Postponing the July Meeting
> >
> > Hi all!
> >
> > Looking at the calendar, it would be time for the July Meeting today.
> > However, I didn't receive any agenda proposals and also forgot to
>
> announce it
> > in the course of releasing 0.4.9.
> > So I suggest we postpone the meeting to next week's Thursday, August 2.
> >
> > Please send agenda proposals by then.
> > That meeting also allows us to handle last-minute planning regarding the
> > Hackfest.
> >
> > Best regards,
> >
> > Colin
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

We could keep components in the reactos git project and just create a new repo for them, however it might still get lost/overshadowed slightly by the main reactos codebase. Another option would be to create a new separate project with one\multiple repos. This would allow us to truly separate components from the reactos project and try to generate interest on their own merit.

We'd need to maximize their visibility by adding a good README.rd files with plenty of buzzwords for the google crawler bot to pick up.

If it was successful and we decide to do more, then we'd need to come up with a format as to how to best manage multiple components.
Do we have individual repos for each component, which allows dedicated README.rd files? This would give maximum flexibility and allow us to have a separate README.rd for each component.
Do we bundle everything into one repo similar to how the WDK samples are setup? This is easier to manage, but less convenient for end users, and won't be as visible for people to find in google searches.

Ged.

-----Original Message-----
From: Ros-dev [e-mail] On Behalf Of Hermès BÉLUSCA-MAÏTO
Sent: Wednesday, 01 August 2018 20:20
To: 'ReactOS Development List' [e-mail]
Subject: Re: [ros-dev] Postponing the July Meeting

Hi,

This sounds interesting, for potential developers wanting just to work on some module, but not wanting to deal with the whole OS thing.
Would this mean that we also have to think about git submodules? Because (in the case of the NTFS driver for example) it would be in a different git repo, and then it would have to be automatically downloaded and updated whenever one of the core ROS dev updates his own ROS git repo.

Cheers,
Hermes
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]] De la part de Ged 
> Murphy Envoyé : mercredi 1 août 2018 20:16 À : 'ReactOS Development 
> List'
> Objet : Re: [ros-dev] Postponing the July Meeting
>
> I have an item for the agenda. I'd like to discuss the possibility of 
> moving some of our drivers out of the main repo and into something more convenient.
>
> In case I don't make the meeting, I'll put forward some of my reasons here:
>
> This thought has come about due to the btrfs driver which we use from 
> Mark Harmstone. Mark's project receives quite a bit of interest on 
> github, and I'm assuming one of the reasons is that it's so easy to 
> find and build. Searching for 'btrfs windows' lists his project as the 
> top hit in google, and building is as simple as cloning, opening the 
> project in VS and clicking build (assuming you have the
> WDK)
>
> I'm wondering if we did the same thing to some of our drivers, we 
> might generate more interest in them. A good example would be our NTFS driver.
> When searching for open source NTFS solutions you're only really given 
> Linux and Max options. The reactos driver is buried deep in the search 
> list, and you only see it if you know what you're looking for. Next if 
> you want to build it, you need to clone the main reactos repo, install 
> the build tools, setup and build the environment, build the tool 
> chain, build the linkers libs, etc, etc. There are so many barriers 
> for people who aren't part of the reactos development team that the chance of getting anyone interested in it are practically zero.
>
> This process would be much simpler if the code was available to clone 
> as a separate project, and could simply build with the WDK and VS. 
> There's then a chance that it might start to generate interest, and 
> people may start working on it instead of it just bit-rotting deep in our main repo.
>
> If we're going to do that, why not consider others too. Network cards, 
> sound stack, USB, boot loaders, printer drivers, directx, etc, There's 
> lots of things that people might be interested in working on and using 
> if they weren't tied to the reactos code base. We obviously benefit 
> from any external interest, and simply pull/import it back into the reactos project.
>
> Ged.
>
> -----Original Message-----
> From: Ros-dev [e-mail] On Behalf Of Colin Finck
> Sent: Thursday, 26 July 2018 17:58
> To: 'ReactOS Development List' [e-mail]
> Subject: [ros-dev] Postponing the July Meeting
>
> Hi all!
>
> Looking at the calendar, it would be time for the July Meeting today.
> However, I didn't receive any agenda proposals and also forgot to 
> announce it in the course of releasing 0.4.9.
> So I suggest we postpone the meeting to next week's Thursday, August 2.
>
> Please send agenda proposals by then.
> That meeting also allows us to handle last-minute planning regarding 
> the Hackfest.
>
> Best regards,
>
> Colin
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Am 01.08.2018 um 20:16 schrieb Ged Murphy:
> I have an item for the agenda. I'd like to discuss the possibility of moving some of our drivers out of the main repo and into something more convenient.
> [...]
> If we're going to do that, why not consider others too. Network cards, sound stack, USB, boot loaders, printer drivers, directx, etc

Using Git submodules to make ReactOS more manageable and increase its
exposure was also my ultimate vision prior to the Git move.
However, after a vivid discussion back then, we had damn good reasons
for sticking with a Monorepo.

First, take into account that Git submodules come with their own drawbacks:

1) If you branch from "master" in our "reactos" repository, its
submodules will stay on "master". In a branch workflow, you basically
have to create a branch for each submodule you want to touch and then
update submodule links.

2) Git always checks out submodules at their root paths. There is no
way to include just a subdirectory of a submodule. This can be
problematic if you want a submodule to make sense on its own and as part
of the big "reactos" repository at the same time.

3) You need more commits to achieve the same, because you first commit
into the submodule and then commit to "reactos" to update the submodule
link. This can be annoying when there are lots of submodules.

There are alternatives like "subtrees" and Google's "repo" tool, but
they come with their own drawbacks, most notably worse support from our
toolchain.
People involved back then may check out the "Reactos Git migration plan"
and "Git Migration Decisions" Google Docs files from that time, as well
as the mailing list discussions. There are also numerous blog posts
about failed migrations to Git submodules.
Let me quote from our decisions back then:

* "There are no modules yet that can be built on their own or which
are big enough to justify a split from the main repository at this point."

* "components should only be split into separate repo if the component
factored out is useful on its own [and] if the component is HUGE and
optional"

So if people still want to split off components into separate
repositories, we first have to do our homework. In my opinion, this
includes:

* Providing a minimal CMake-based ReactOS SDK that can compile both a
single component like Paint and the entire OS.

* Deciding on a generic structure for each submodule to come:
README.md, directories, where bugs are filed, Continuous Integration

For the bugs part, we could actually create a JIRA project for each
submodule and move existing bugs there.
Regarding Continuous Integration, our BuildBot should be made more
flexible to accept in-tree configuration files (like Travis-CI). It
would then be able to serve standalone projects as well. BuildBot 0.9.x
supports "BuildBot Travis" for that.
Of course, we could also go fully Travis-CI/AppVeyor, but then we're in
serious trouble if they ever cease service. Additionally, jobs may be
queued for a long time if their servers are overloaded.

Finally, always consider whether a module serves a real purpose on its
own. For instance, BTRFS is something Windows doesn't offer, so it has a
huge exposure on GitHub. On the contrary, NTFS is something Windows can
usually do better, so our own NTFS driver may hardly be popular as a
separate project. However, I would love to be proven wrong on this!

Best regards,

Colin

[Colin Finck]

Invitations have been sent, please check your inboxes!

Colin

Am 26.07.2018 um 18:57 schrieb Colin Finck:
> Hi all!
>
> Looking at the calendar, it would be time for the July Meeting today.
> However, I didn't receive any agenda proposals and also forgot to
> announce it in the course of releasing 0.4.9.
> So I suggest we postpone the meeting to next week's Thursday, August 2.
>
> Please send agenda proposals by then.
> That meeting also allows us to handle last-minute planning regarding the
> Hackfest.
>
> Best regards,
>
> Colin
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev