"jgart" <jgart@dismail.de> writes:
Toggle quote (17 lines)
>> This aligns with the current (and previous) guidance on managing
>> branches [1]. Providing there's a consistent topic for the branch, any
>> name is fine (e.g. python-team-sphinx is fine).
>
> That's great that my proposal already aligns with the current guidance.
>
> I am going to try to start cherry picking uncontroversial and non
> failing patches on the python-team branch on to master and removing
> them from the python-team branch in order to reduce the size of the
> branch. I can then remove those commits from the python-team branch
> and force push to update it. What do you think of this approach before
> I attempt it? I'll wait on your guidance before doing this.
>
> Another approach I can take is to break the branch apart into 2 or 3
> smaller topic branches and make requests for those branches to merge
> one at a time.
If there are commits on the branch that have been submitted as patches,
you might just be able to look at pushing them to master. If there are
commits that haven't been submitted as patches yet, but could be pushed
to master, it would be good to send them as patches so that QA can take
a look.
And splitting off some commits in to a more specific branch is fine as
well.
Toggle quote (6 lines)
> Note that I have an underpowered old Thinkpad X230 laptop and will
> only be able to test branches that are not too large. I tried using
> QA/CI but it seemed to be in an unknown state the last time that I
> tried. Any suggestions here for how to more effectively use that QA/CI
> infrastructure would be much appreciated.
QA has been performing recently as it's taking too long to process
revisions. Let me know if things aren't working or if you have questions
though and I can try and help.
Toggle quote (13 lines)
> I tried spending a bit of time on trying to resolve the merge
> conflicts but it quickly lead down a long rabbit hole and I only have
> a limited time to fix so many merge conflicts. The process is also
> currently very tedious to do with high amounts of accuracy due to
> their being
>
> 1. Lots of commits that I am not familiar
> 2. Lots of commits
> 3. The branch has diverged alot since latest master so things don't cleanly apply anymore
>
> What do you think of this current approach of cherry picking good
> commits off of the python-team branch in order to reduce the size?
I think making sure commits that can go to master, do go to master, is
really helpful to avoid merge conflicts. It's so much more likely to
have conflicts if there are changes that can be made on master, but are
made on a branch, or changes that should be made on a branch but are
pushed to master.
Toggle quote (5 lines)
> Another issue that I ran into on the branch is that there are commits
> that are failing. For example, at commit
> fdef5662cce6a57aa6bfa682c7260b65ce3669b8 (the borgmatic changes),
> borgmatic fails. Should I remove this commit since it is broken?
While ideally we'd care about the state at each commit, this doesn't
really happen so it's up to you what you do there.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmaBKIlfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XdLXA/8DGE+vIx2DyAATEljF+IIn8cxhrFmwz2z
70CPTgoS+sOWf5ulSlZWqFTj4y8Cy6pv6b3Fw2IPSkW8iuVIjCT3Z0XNUx4tqTW1
Iv/eP3+qRPW6D11dDTBz8Qzd9XX3FuIia0DEmKjk+Yt140jvhZJMQRzYQQMs0/Jp
srHKusCa9/NZOjzOErmGPJSnbPbekUS9mR/zMS27OyC+uEnZNgL1Jp/pW7SPyZXN
aJLeraKhQN7NPchx9zUbeZUpl+tgJIjHcpf4neqedyYwxLEjn2iOYcapZ0z4uvC/
LJEtlxNFDZjG6y3pmbFoBHHQoVmtRJ2+qcQshzyscKqzmcZfvFSZ8AQ804FuIjEq
q/7lQZuJFAXEd4941E/ukdVoyAnuvd54YpECIs7OENuZ1BmCSHtOvJYkD/DKnp7q
bQb1hPz3pzumCs5WnROsA6JKEj8je3KLq5/uymP2OtwAco5NLB2K7kM0hY/Zl9my
8AQXyYXXh4HRqkvBTr6UmN5CLBGM7p6+wMo83/vXDiM7kV8stsnARVEr45DBMWix
v7ikVKoNbeY1Besvr5BZld0vgNa9UNVwLIU8X9nfsvgOn23sdcaYB0v1/bl1QumT
UM//or6diwyMFG2zz6zSWF2oqid0C7AmhdmHikVZr37t3Ou4zGB7UoaK88vnlhrf
6eXNQfeJhmw=
=GDnz
-----END PGP SIGNATURE-----