Fw: GSoD 2022 clarification requested

[Deepak Vohra via dev]

 Please refer reply forwarded from the Season of Docs Support for providing an 
Open Collective account. 
   - Forwarded Message - From: Season of Docs Support 
To: Deepak Vohra Cc: 
"dev@cassandra.apache.org" ; Season of Docs 
Sent: Thursday, March 10, 2022 at 03:38:10 p.m. 
ESTSubject: Re: GSoD 2022 clarification requested
 Thank you for reaching out, Deepak.
If you don’t have a bank account for your project, you can sign up with Open 
Source Collective to be your fiscal host, which means they will hold the funds 
on your behalf as you pay them out. No fees from Open Source Collective will 
apply to your grant payment.  You can find more information on grants and 
opening an Open Collective account here or email Open Collective directly for 
more information through supp...@opencollective.com.
Regarding technical writers, please review the selecting a technical writer 
guide and our GitHub page.

Best,Season of Docs team
On Wed, Mar 9, 2022 at 6:17 PM Deepak Vohra  wrote:

Google program administrator

Apache Cassandra, an open source project under Apache Software Foundation 
(ASF), and a GSoD 2019-20 participant,  might be interested in applying as an 
organization to GSoD 2022. Apache Cassandra mainly does code development and 
documentation and is not structured for the administrative tasks of collecting 
a GSoD grant if accepted, hiring technical writer/s, and disbursing grant funds.
How could Apache Cassandra apply as an organization?
thanks,Deepak 


-- 
You received this message because you are subscribed to the Google Groups 
"Season of Docs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to season-of-docs+unsubscr...@google.com.
To view this discussion on the web visit 
https://groups.google.com/a/google.com/d/msgid/season-of-docs/CADLXuaTBSOV5prc-TCbSCnncTBDBvwE104JAHk_6DOta4GLt%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/a/google.com/d/optout.

  

Re: GSoD 2023

[Deepak Vohra via dev]

 GSoD 2023 was announced yesterday 
https://developers.google.com/season-of-docs/docs/timeline
On Wednesday, January 18, 2023 at 09:33:44 p.m. EST, Lorina Poland 
 wrote:  
 
 Hi Deepak -

I'll have more to post soon, but I have started working on a proposal for GSoD 
2023 for Apache Cassandra. Keep an eye out for that post.

On 2023/01/11 09:56:36 Deepak Vohra via dev wrote:
> Lorina,
> Happy New Year.
> You mentioned this year you might apply. As I am interested in being the Tech 
> Writer, a reminder to apply as applications are to open from January to March 
> according to 
> https://sites.google.com/view/gsoc-sod-fosdem-2023/google-season-of-docs. 
> Detail yet to be posted for  GSOD 2023.
> regards,Deepak
  

Downtime for multiple Jenkins Controllers

[Gavin McDonald]

Hi All,

This coming Sunday, the following Jenkins Controllers will be taken down
for software upgrades and an internal DNS change, the service names will
be unaffected and no action is needed on your part.

Downtime for each should be about 1/2 hr and will take place sometime
between 9am and 2pm UTC, Each Controller will be placed in shutdown mode
a few hours before if needed to allow in progress builds time to complete.

ci-builds.apache.org
ci-hadoop.apache.org
ci-beam.apache.org
ci-maven.apache.org
ci-hbase.apache.org
ci-cassandra.apache.org

Thanks in advance for your patience.

Gavin (ASF Infra)

Re: Intra-project dependencies

[Mick Semb Wever]

Thanks David for the detailed write up. Replies inline…



> We tried in-tree for in-jvm dtest and found that this broke every other
> commit… maintaining the APIs across all our supported branches was too hard
> to do and moving it outside of the tree helped make the upgrade tests more
> stable (there were breakage but less frequent)….
>


The in-jvm dtest-api library is unique in this way. I would not use it as
reasoning that other libraries should not be in-tree.




> We tried to do snapshot builds where the version contained the SHA, but
> this has the issue that snapshot builds “may” go away over time and made
> older SHAs no longer building…
>


Only keeping the last snapshot in repository.a.o is INFRA's policy (i've
found out).
We can ask INFRA to set up a separate snapshots repository just for us,
with a longer expiry policy. I'd rather not create extra work for infra if
there's other ways we can do this, and this approach would always require
some fallback approach to rebuilding the dedepency's SHA from scratch.




> We break python-dtest when cross-cutting changes are added as CI is hard
> to do correctly or not supported (testing downstream users (our 4 supported
> branches) is rarely done).
>


python dtests' is also in a different category, (the context and
consumption in a different direction, i.e. it's not a library used within
the in-tree).



> * [nice to have] be able to work with all subprojects in one IDE and not
> have to switch between windows while making cross-cutting changes
>


Isn't it only IntelliJ that suffers this problem? (That doesn't invalidate
it, just asking…)



>  - same with `git pull …` (easy to be left with out-of-sync submodules)
>
>
> Correct, if you use submodules/script you have a text file saying what we
> “should” use, but this does not enforce actually using them… again we could
> make sure build.xml does the right thing,
>


If we try this approach out, I'm definitely in favour of any build.xml
command immediately failing if `git submodule status` != `git submodule
status --cached`



> but this can be confusing for people who mainly build in IDE and don’t
> depend on build.xml until later in development… this is something we should
> think about…
>


Again, isn't this only IntelliJ?



> A project I am familiar with has their build auto-inject git hooks to make
> sure things “just work”, we may be able to solve this in a similar way?
>


I'd like to hear/see more!

 - permanence from a git SHA no longer exists
>
>
> Why is this?  The SHA points to other SHAs, so it is still immutable.  If
> we claim that pointing to other SHAs doesn’t count then why do library
> versions?  Both are immutable snapshots of code at a specific point in time?
>


This, and a number of the other points, is already resolved (that
submodule's are on fixed SHAs, not floating HEAD).

 - our releases get more complicated (our source tarballs are the asf
> releases)
>
>
> We don’t include our dependencies do we?  If so, then does it really?  If
> Accord is a library we use, why would we include it’s source in the build?
> Isn’t it just another library from this point of view?
>


The build of the source tarball must work. If the source tarball release
switches how it does things, from building the submodule to including a
dependency then we're back to having to make releases (and introducing a
risk, and we don't ourselves work frequently with the source tarballs).




> switching between branches,
>
>
> This is a pain point that I feel should be handled by git hooks.  We have
> this issue when you try to reuse the same directory for different release
> branches, and its super annoying when you go back in time when jars were
> in-tree as you need to cleanup after switching back…. I do agree that we
> should flesh this out as its going to be the common case, so how do we “do
> the right thing” should be handled
>


+1



> Rather that you need to know in advance when the SHA is not HEAD.
>
>
> Do you?  Or do you really need to know which “branch” it is following?
> For example, lets say we release 5.0 then 5.1 then 5.2, and there are
> accord versions for each: 1.0, 1.2, 2.0… do we not need to really know
> which branch it is following, and only when you are trying to do a
> cross-cutting change?
>

I'm still a little confused here. If a submodule is following a branch, is
that floating? Then a parent SHA isn't fixed to a submodule SHA?

Say trunk is using accord:a12 where a12 is a SHA on its trunk. Other
non-cassandra people using accord make commits, but our in-tree trunk isn't
moved forward. Then someone in-tree does some dev that touches accord, they
work away but late in the dev cycle find out that in-tree trunk isn't on
the latest accord trunk and there's a conflict rebasing their work onto the
latest accord. Is this an accurate description?

Hope that all makes sense.

[DISCUSS] Formation of Apache Cassandra Publicity & Marketing Group

[Patrick McFadin]

*Hello Cassandra Community!We are at a pivotal moment for the Cassandra
community, with the first Cassandra Summit in 7 years coming up on March
13th, and a major release coming later this year with Cassandra 5.0. It is
important that we come together to set the publicity strategy and direction
for these important moments, and that we work together to define how
Cassandra shows up across the technology industry.To achieve this, we are
proposing the formation of a Publicity & Marketing Working Group, and we
are requesting your participation.What is the Publicity & Marketing Working
Group?This is a working group open to community members who have the
insight and skills to help define Cassandra’s public narrative and
participate in our marketing strategy and execution. The group will meet
once a month for an hour to discuss important marketing topics. You can
find us on #cassandra-events. We also propose adding a mailing list,
marketing@cassandra.a.o, to handle day-to-day marketing needs and async
communication. Our publicity and marketing partners from Constantia - Molly
Monroy  and Melissa Logan  -
will work with us to build this working group. What will this group be
responsible for?Our initial vision for this group is to accelerate how we
do marketing & publicity for Cassandra. We will refine and advance
Cassandra’s public perception of the tech industry, to show how Cassandra
has grown, innovated, and revitalized itself as a community. We will do
this through: - Participating in marketing strategy for major moments (in
particular, C* Summit in March and Cassandra 5.0 release later this year)-
Expanding our local meetup and events presence- Sourcing end-user case
studies for marketing and PR collateral- Making sure the Cassandra
community shows up at third-party events- Contributing content - from blogs
to documentation - to ensure we have a robust stream of content for our end
usersOur first two orders of business will be: 1. Jointly determine
operating model and governance, and get input and alignment on the above
goals/responsibilities. 2. Discuss marketing for Cassandra Summit,
primarily defining the news we will share at the event from the project
directly and from our sponsors. This is coming up quickly and we will need
community assistance to achieve our publicity goals. As this is a
community-driven group, please share ideas and feedback on the purpose of
this group and what we need to achieve. When is the meeting?We are
proposing the meetings take place on the 4th Wednesday of each month. We
will alternate times of the day to try to accommodate. We can adjust based
on member attendance.  - Jan, March, May, July, Sept, Nov.  - 4th Wed of
the month,  8a PT- Feb, April, June, August, October, Dec - 4th Wed of the
month, Wed 4p PTWe will create a centralized document to share and document
information about the working group, including meeting minutes, monthly
tasks, and priorities. Decisions will be discussed and finalized using the
project mailing list. Patrick*

Re: Intra-project dependencies

[David Capwell]

Thanks for the reply, my replies are inline to your inline replies =D

> On Jan 19, 2023, at 2:39 PM, Mick Semb Wever  wrote:
> 
> 
> Thanks David for the detailed write up. Replies inline…
> 
>  
> We tried in-tree for in-jvm dtest and found that this broke every other 
> commit… maintaining the APIs across all our supported branches was too hard 
> to do and moving it outside of the tree helped make the upgrade tests more 
> stable (there were breakage but less frequent)…. 
> 
> 
> The in-jvm dtest-api library is unique in this way. I would not use it as 
> reasoning that other libraries should not be in-tree.

Fair, its the only API we have that is required to be byte code compatible 
cross versions/builds; this unique property may argue for different solutions 
than others

> 
> 
>  
> We tried to do snapshot builds where the version contained the SHA, but this 
> has the issue that snapshot builds “may” go away over time and made older 
> SHAs no longer building… 
>  
> 
> Only keeping the last snapshot in repository.a.o is INFRA's policy (i've 
> found out).
> We can ask INFRA to set up a separate snapshots repository just for us, with 
> a longer expiry policy. I'd rather not create extra work for infra if there's 
> other ways we can do this, and this approach would always require some 
> fallback approach to rebuilding the dedepency's SHA from scratch.

If they will allow this and allow the snapshots to never be purged, then I am 
ok with this as a solution.

> 
> 
>  
> We break python-dtest when cross-cutting changes are added as CI is hard to 
> do correctly or not supported (testing downstream users (our 4 supported 
> branches) is rarely done).  
> 
> 
> python dtests' is also in a different category, (the context and consumption 
> in a different direction, i.e. it's not a library used within the in-tree). 

I disagree.  The point I was making is we have several dependencies and we 
should think about how we maintain them.  My point is still valid that python 
dtests are involved with cross cutting changes to Cassandra, and the lack of 
downstream testing has broken us several times.  The solution to this problem 
may be different than Accord (as C* doesn’t depend on python dtest as you point 
out), but that does not mean we shouldn’t think about it in this conversation….

One thing that comes to mind is that dependencies may benefit from running a 
limited C* CI as part of their merge process.  At the moment people are 
expected to create a tmp CI branch for all 4 supported C* versions, point it to 
the python dtest change, then submit to the JIRA as proof that CI was ran… 
normally when I find python dtest broke in branch X I find this had not 
happened… 

This holds true I believe for JVM dtest as well as we should be validating that 
the 4 target C* branches still work if you are touching jvm dtest…

Now, with all that, Accord being external will have similar issues, a change 
there may break Cassandra so we should include a subset of Cassandra tests in 
Accord’s CI.

> 
>  
> * [nice to have] be able to work with all subprojects in one IDE and not have 
> to switch between windows while making cross-cutting changes
> 
> 
> Isn't it only IntelliJ that suffers this problem? (That doesn't invalidate 
> it, just asking…)

I have not used Eclipse or NetBeans for around 10 years so no clue!  

> 
>   
>>  - same with `git pull …` (easy to be left with out-of-sync submodules)
> 
> Correct, if you use submodules/script you have a text file saying what we 
> “should” use, but this does not enforce actually using them… again we could 
> make sure build.xml does the right thing,
> 
> 
> If we try this approach out, I'm definitely in favour of any build.xml 
> command immediately failing if `git submodule status` != `git submodule 
> status --cached`

+1

> 
>  
> but this can be confusing for people who mainly build in IDE and don’t depend 
> on build.xml until later in development… this is something we should think 
> about…
> 
> 
> Again, isn't this only IntelliJ?

Not sure, the only other IDE we support is NetBeans and not sure what we do 
there. 

> 
>  
> A project I am familiar with has their build auto-inject git hooks to make 
> sure things “just work”, we may be able to solve this in a similar way?
> 
> 
> I'd like to hear/see more!

The project wants to make sure commit messages are structured “correctly” so 
enforces this via git hooks.  Gradle (the build they use) makes tasks depend on 
“installGitHooks” which copies 2 hooks to .git/hooks (commit-msg, and pre-push)


We could always do the same in build.xml, that copies hooks we define into 
.git/hooks to make sure the behaviors we expect are enforced.  See 
https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks 



There is a “post-checkout” hook we could leverage to detect that the 
dependences SHA are no longer the same and recursively checks out the “correct” 
dependencies