Re: [PureOS] Updating localechooser in landing/byzantium
Quoting Guido Günther (2021-10-09 17:11:27)
Hi, On Sat, Oct 09, 2021 at 10:25:20AM +0200, Carsten Schoenert wrote: [..snip..]
https://source.puri.sm/pureos/packages/lollypop contains no local feature commits (i.e. no feature changes, only boilerplate changes to packaging metadata) so does not illustrate well how to best tackle package upgrades. What it does illustrate is that it didn't preserve earlier PureOS work - i.e. the work tracked at https://source.puri.sm/librem5-apps/lollypop
That is unfortunately correct. :( I wasn't aware that there was already a lollypop tree until now. Then we need to think about how get that split fixed.
I wasn't aware of
https://source.puri.sm/librem5-apps/lollypop
when importing, sorry.
We can preserve that history in the pureos/packages/lollypop repo need be or just leave it as is and use that fork in unlikely case we need updates for amber-phone. Both works for me.
That particular work of mine is not important for me that we preserve. If topic of this conversation is _simplest_ practice then let's just throw away historic git repos. I pointed to that historic git repo because a) it was unclear to me what Carsten wanted to say (he also referenced missing posts by Guido still unavailable to me¹), and b) I mistakenly focused on finding _best_ practice. - Jonas ¹ Seems many posts from Guido has reached only cc'ed participants in discussions, not this list. As a concrete example, this email is a response to an email from Guido with Message-ID <YWGxH0nt5AnmfYO9@qwark.sigxcpu.org> which I received but does not appear at https://lists.puri.sm/pipermail/pureos-project/2021-October/thread.html -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
After a week which mostly has consumed all my energy for $dayjob I'm now looking again into solving the original issue. Am 09.10.21 um 17:50 schrieb Jonas Smedegaard: ...
We can preserve that history in the pureos/packages/lollypop repo need be or just leave it as is and use that fork in unlikely case we need updates for amber-phone. Both works for me.
That particular work of mine is not important for me that we preserve.
If topic of this conversation is _simplest_ practice then let's just throw away historic git repos.
The lollypop repos are bit out of scope of the original reason for this discussion ... to me it's mostly helpful if I can follow not only a recent development but also past development (if it's not done for pre sarge :P ). For sure we can combine the two trees into one were all the PureOS related modification are visible. This would require further work of course. So a compromise from a POV of needed effort for me would be to keep the things how they are right now and maybe through away the old amber-phone-stuff after amber has becoming unsupported. If I'm feeling boring I can cherry-pick (or someone other) the old changes into the current most recent lollypop repo so the old tree could be removed earlier.
I pointed to that historic git repo because a) it was unclear to me what Carsten wanted to say (he also referenced missing posts by Guido still unavailable to me¹), and b) I mistakenly focused on finding _best_ practice.
O.k. I might have not made it fully clear what my objection was. I'd like to avoid to do work that is in my eyes more error prone than the workflow I use for several years now if I do Debian packaging and I've also have seen within a lot of other packages by developers which I not know directly or have spoken too except by some email exchange maybe. And I'd like to easy see what happen in the past within one or more packaging (git) trees. That's the main reason why I've suggest the renaming / migration of the current existing packaging tree for localechooser together with a pull in of the tree from Salsa. It's of also possible to start from scratch and cherry-pick the existing commits from the current tree. But both ways require additional extra intrusive action on source.p.s. As I'm not able to do this without some help from users who are able to do this (nor want to do this without an acknowledge from others) we need to come to an agreement how we all can be happy. @Guido @Jonas @Matthias If you think I tend to start more work than needed then it's best that a counter example would be done which I'm happily adopt for other packages. I looked into some repositories now already, but it's still a bit hard for me to get a feeling how derived packages get handled best here as I'm only able to look at things for a few hours a week. -- Regards Carsten Schoenert
Quoting Carsten Schoenert (2021-10-16 13:34:27)
After a week which mostly has consumed all my energy for $dayjob I'm now looking again into solving the original issue.
Am 09.10.21 um 17:50 schrieb Jonas Smedegaard: ...
We can preserve that history in the pureos/packages/lollypop repo need be or just leave it as is and use that fork in unlikely case we need updates for amber-phone. Both works for me.
That particular work of mine is not important for me that we preserve.
If topic of this conversation is _simplest_ practice then let's just throw away historic git repos.
The lollypop repos are bit out of scope of the original reason for this discussion ... to me it's mostly helpful if I can follow not only a recent development but also past development (if it's not done for pre sarge :P ). For sure we can combine the two trees into one were all the PureOS related modification are visible. This would require further work of course.
So a compromise from a POV of needed effort for me would be to keep the things how they are right now and maybe through away the old amber-phone-stuff after amber has becoming unsupported. If I'm feeling boring I can cherry-pick (or someone other) the old changes into the current most recent lollypop repo so the old tree could be removed earlier.
Maybe I was unclear above, let me try be more explicit: My personal opinion: I see no need for you to incorporate my hostoric lollipop work into yours. With my Purism-policy-nitpicker hat on: We have no policy regarding preservation of historic works, and if we were to establish such policy I would recommend that it would include something like "works containing no feature changes (e.g. only fuzzing and boilerplate changes) need not be preserved" which fit the case of my work packaging lollipop. Now is probably the wrong time and place to discuss creation or changing policy - i.e. let's not discuss policy any furthere here unless to correct me if Purism *already* has an established policy on the matter.
I pointed to that historic git repo because a) it was unclear to me what Carsten wanted to say (he also referenced missing posts by Guido still unavailable to me¹), and b) I mistakenly focused on finding _best_ practice.
O.k. I might have not made it fully clear what my objection was.
I'd like to avoid to do work that is in my eyes more error prone than the workflow I use for several years now if I do Debian packaging and I've also have seen within a lot of other packages by developers which I not know directly or have spoken too except by some email exchange maybe.
I don't understand what you refer to as "more error prone" - but no need to explain what you mean unless you seek _best_ practice, see below... Debian packaging works rarely involve multiple overlapping timelines. Debian-derivative works more often involve multiple parallel timelines, due to the nature of Debian and the derivative distribution often being developed in parallel. But caring about *how* to flatten parallel timelines only matters for _best_ practice: If you don't care about ambiguities on how parallel timelines get flattened by the tools you use, then just use whatever Debian packaging practices you are familiar with and hope for the best... In short: Please ignore all of my posts in this thread if your interest is to use _easiest_ or _simplest_ or _quickest_ practice. Only if your interest is in _best_ practice is my posts here any relevant.
p.s. As I'm not able to do this without some help from users who are able to do this (nor want to do this without an acknowledge from others) we need to come to an agreement how we all can be happy.
For the record: I am frustrated that I feel alone about my views about how to _best_ handle multiple parallel timelines in packaging works. However, your working on PureOS packages makes me happy *regardless* of your packaging style: You are not making things _worse_. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Am 16.10.21 um 15:24 schrieb Jonas Smedegaard:
Maybe I was unclear above, let me try be more explicit:
My personal opinion: I see no need for you to incorporate my hostoric lollipop work into yours.
With my Purism-policy-nitpicker hat on: We have no policy regarding preservation of historic works, and if we were to establish such policy I would recommend that it would include something like "works containing no feature changes (e.g. only fuzzing and boilerplate changes) need not be preserved" which fit the case of my work packaging lollipop.
Now is probably the wrong time and place to discuss creation or changing policy - i.e. let's not discuss policy any furthere here unless to correct me if Purism *already* has an established policy on the matter.
I fully agree. Let's do some work.
I pointed to that historic git repo because a) it was unclear to me what Carsten wanted to say (he also referenced missing posts by Guido still unavailable to me¹), and b) I mistakenly focused on finding _best_ practice.
O.k. I might have not made it fully clear what my objection was.
I'd like to avoid to do work that is in my eyes more error prone than the workflow I use for several years now if I do Debian packaging and I've also have seen within a lot of other packages by developers which I not know directly or have spoken too except by some email exchange maybe.
I don't understand what you refer to as "more error prone" - but no need to explain what you mean unless you seek _best_ practice, see below...
Debian packaging works rarely involve multiple overlapping timelines.
Debian-derivative works more often involve multiple parallel timelines, due to the nature of Debian and the derivative distribution often being developed in parallel.
But caring about *how* to flatten parallel timelines only matters for _best_ practice: If you don't care about ambiguities on how parallel timelines get flattened by the tools you use, then just use whatever Debian packaging practices you are familiar with and hope for the best...
In short: Please ignore all of my posts in this thread if your interest is to use _easiest_ or _simplest_ or _quickest_ practice. Only if your interest is in _best_ practice is my posts here any relevant.
I'll always be interested in technical discussions as I hardly believe that only the exchange about different POVs will be the base for finding the best ways to solve problems and issues. And so also here I'm happy to have learned new things and other possible solutions. Once we meet up again $somewhere we will enjoy one or two beer together!
p.s. As I'm not able to do this without some help from users who are able to do this (nor want to do this without an acknowledge from others) we need to come to an agreement how we all can be happy.
For the record: I am frustrated that I feel alone about my views about how to _best_ handle multiple parallel timelines in packaging works. However, your working on PureOS packages makes me happy *regardless* of your packaging style: You are not making things _worse_.
O.k. thank you!! -- Regards Carsten Schoenert
participants (2)
-
Carsten Schoenert -
Jonas Smedegaard