[Openpvrsgx-devgroup] New version letux-pvrsrvkm-v5.6.0-rc1 available

Andreas Kemnade andreas at kemnade.info
Tue Feb 18 22:47:03 CET 2020


On Tue, 18 Feb 2020 20:55:54 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

> Hi Andreas,
> 
> > Am 18.02.2020 um 20:40 schrieb Andreas Kemnade <andreas at kemnade.info>:
> > 
> > On Tue, 18 Feb 2020 15:30:10 +0100
> > "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> >   
> >> Hi Tony,
> >>   
> >>> Am 18.02.2020 um 15:06 schrieb Tony Lindgren <tony at atomide.com>:
> >>> 
> >>> * H. Nikolaus Schaller <hns at goldelico.com> [200218 05:42]:    
> >>>> Hi Tony,
> >>>>   
> >>>>> Am 17.02.2020 um 23:19 schrieb Tony Lindgren <tony at atomide.com>:
> >>>>> 
> >>>>> * H. Nikolaus Schaller <hns at goldelico.com> [200217 21:48]:    
> >>>>>> letux-pvrsrvkm-v5.6.0-rc2 will be different of course but also
> >>>>>> stay stable.    
> >>>>> 
> >>>>> Argh no.. Please just stop doing this pointless weekly respinning
> >>>>> of branches stuff. There's absolutely no point setting up a new
> >>>>> git branch for every Linux -rc kernel every week. That's just
> >>>>> silly.    
> >>>> 
> >>>> No. I have explained the reasons.    
> >>> 
> >>> Sorry this rebuilding of git trees does not work for me for Linux
> >>> kernel driver development.    
> >> 
> >> Can you please explain, since it seems I still have not yet understood
> >> your problem and how a "standard way" would be better.
> >>   
> >>> It's too much of a pain for me already and I only have two sets of
> >>> patches so far (for ddk 1.9 and ddk 1.17).    
> >> 
> >> So what is the pain?
> >> 
> >> In my understanding it suffices to git checkout letux-pvrsrvkm-v5.6.0-rc1
> >> and add new commits to it. And let me know if you have new ones. Then I
> >> can cherry-pick them into the feature branches (like I have done this
> >> time).
> >> 
> >> If you want to take patches from letux-pvrsrvkm-v5.6.0-rc2 just cherry-pick
> >> them or decide to rebase.
> >>   
> > hmm, I can understand the point here. Cherry-picking and comparing what is new
> > is more cumbersome than just merging. There are some things different here
> > compared to what happens in letux trees. So if something was good in letux it
> > does not necessarily mean that it is good here.
> > - here more people work more intensively on a single, quite big topic.
> > - on letux we had often one person per topic,
> > - on letux we have many branches which are in upstream process and there
> >  things are rebased anyways to work in maintainers/reviewers comments and
> >  have a topic-v(x+1) branch aftervards
> >  or stalled because things seem not to or too hard to be upstreamable
> > - many things happend and were upstreamed before this rebasing scripts
> >  were in place
> > - many things in letux branches now can simply be developed independently
> >  of other letux stuff
> > 
> > So I think it is a good time to recheck the workflow for this different
> > situation.  
> 
> Indeed - we have quite contradicting requirements/expectations for the
> workflow. And I understand that we need to have both. Somehow combined :)
> 
> > And please do not stop working together because you have different
> > opinions about git.
> > 
> > I guess it is a good chance to learn a lot. Hmm, what about
> > rebasing the pvrsrvkm stuff only at -rc1 and merging that thing also
> > into letux-rcX (X >1) kernels. I guess we will have everything then and in a
> > simple way.  
> 
> Hm. Yes, that could potentially help here.
> 
> But I am not sure if I can automate it easily... Basically the merge
> is a script with a control file that tells which branch names should be 
> rebased/merged into a single result (or multiple). Similar to the
> linux-next control file.

and there you might simply mark same branches as merge-only (or pattern-matching
if it contains kernel version number, maybe), and handling the rebasing process
for those separately.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/openpvrsgx-devgroup/attachments/20200218/8e750c95/attachment.asc>


More information about the openpvrsgx-devgroup mailing list