[Geany-Devel] Helping Geany move forward: testing

[Lex Trotman]

...
>> I have to agree with Matthew that:
>>
>> 1. Nobody wants to break master because its what everybody is using.
>> Problem is that if we had a development branch nobody would be using
>> it because it might break, so its insufficiently tested.  I don't have
>> a solution to that.
>
>
> master *is* the development branch. It's not a stable branch that must not
> be broken at all costs. It's also not true that everyone is using master.
> The vast majority is using releases, and in fact we do regular releases so
> that we can use master as a true development branch.

The vast majority are therefore not testing anything in master prior
to release, so they are not helping stabilise the release.  Thats no
help. (Of course users are not expected to help stabilise the
release).

> Even I don't use master
> (a very regular contributor) for my clone that I use daily. I always fork
> the last release, merge my changes, and backport individual commits from
> master (via cherry-pick). Of course I develop features based on master, so I
> do test the master branch on a regular basis.

So you don't do much testing of any changes in master, except those
you choose to backport to your day to day version, or that you happen
to use when testing your own Geany development.

Some of us do use git HEAD (or close to, I'm a bit behind ATM) so we
do check what will be in the next release, at least for those things
in our normal workflow.  Otherwise if nobody used HEAD it would be
extremely lightly tested come release time.

Besides emacs and atom I havn't looked at how other editor projects do it.

But certainly emacs has most of their devs using HEAD or close to it,
and they also try to be careful about what they commit.  But of course
thats not a github project so they get fewer external contributions
and most have been through mailing list hell before they get applied.

Atom takes a different approach of being very modular and having each
part in a separate repository, over 200 according to their
CONTRIBUTING.md.  Therefore its more akin to geany-plugins, where
individual parts can be easily handled separately.  And they seem to
make heavy use of feature branches in the main repos.  Don't think
that will work with a monolithic C application like Geany.

>
> So yes, if you are afraid of doing development on the development branch,
> it's clear that we're struggling to get anything done. Sure, one can expect
> that PRs are perfect before getting merged, but the current situation shows
> that this is not working if you want to get something done in a timely
> manner.

It seems that the result of what you are advocating is to release less
tested more buggy versions?  Or am I misunderstanding the result?

>
> From another angle, both of you could easily create a development branch.
> But you didn't so far. Anyway, how is that workflow supposed to work? If
> lots of PRs go through an intermediate branch then merging that intermediate
> branch into master is going to be a nightmare too.

Which is also true and another reason its not done that way.

Cheers
Lex

>
> Best regards.
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel