Guido,
Am 06.10.21 um 16:38 schrieb Guido Günther:
I've currently decided against this option because to keep the existing old history within the same tree as base for the current new added branch.
…but that wouldn't change since the current history is on `master` and you'd merge that plus your changes / the update into `pureos/latest`, right?
no, my current way of doing nor your point would break or drop history, how you are seeing it, or your pov of doing is just another way to get the same goal. The merge of the old master branch is just into another direction than I've done it currently.
Am i missing something? Your merge of the old 'master' wouldn't get broken as long as the merge of the MR to `pureos/latest` is fast-forward.
Sure, to get things merge-able by a MR the repo on core-packages would need an existing branch pureos/latest. That isn't existing right now.
I've tried the readjust the way you would make update for the fork.
1. Create new branch pureos/latest based on Debian tag 2.93 2. Merge in the (old pureos) master branch 3. Add additional stuff as gbp.conf and CI yaml file
The outcome and the required work is the same to my current kind of doing, most of the work is to solve the merge conflicts as this is exact same todo on both ways.
But maybe I'm the one that is missing something. ;)
Again I have no strong opinion here but rather try to understand why one would use a different workflow as with other packages (which e.g. results in the discussion being split between mailing list and giltab).
Well, the thing is still, there is no branch I can start a MR against (at least I think). There is not even yet a tag 2.93 on soure.p.s., there is currently only the old master branch which isn't connected anyhow to the "mother" tree on Salsa. If it would exist at all this mail traffic wouldn't needed and I've started directly any discussion within a MR.
If the outcome is there is no problem to create a starting branch pureos/latest by preparing the tree on source.p.s then I'm of course fine with this. I'm unsure if I would can do that, given to the permissions for Developers I should.
My take for using merge requests for about everything is that it keeps the discussion close to the code (and searchable).
I fully understand this. But I'm quite conservative about possible direct action on "hot" repositories as I'm still new and like to prevent any damages.
Hello,
On 10/6/21 12:29 PM, Carsten Schoenert wrote:
Guido,
Am 06.10.21 um 16:38 schrieb Guido Günther:
<snip>
Again I have no strong opinion here but rather try to understand why one would use a different workflow as with other packages (which e.g. results in the discussion being split between mailing list and giltab).
Well, the thing is still, there is no branch I can start a MR against (at least I think). There is not even yet a tag 2.93 on soure.p.s., there is currently only the old master branch which isn't connected anyhow to the "mother" tree on Salsa.
This is an issue with all packages on source.puri.sm - both pureos/core and pureos/packages are not connected to Salsa or to Laniakea.
These repo groupings (core and packages) likely no longer serve the same purpose as originally - namely to be "complete and corresponding" source code for all the packages in PureOS. We likely ought to have a plan or create one for how we can have a one-to-one correspondence between source code in a git repo and the binaries in the archives to make support easier.
If it would exist at all this mail traffic wouldn't needed and I've started directly any discussion within a MR.
If the outcome is there is no problem to create a starting branch pureos/latest by preparing the tree on source.p.s then I'm of course fine with this. I'm unsure if I would can do that, given to the permissions for Developers I should.
My take for using merge requests for about everything is that it keeps the discussion close to the code (and searchable).
This makes sense but this list can be a very valuable resource for those new to PureOS, for making policy, and for other co-ordination. So I for one welcome Carsten's mail to the list.
I fully understand this. But I'm quite conservative about possible direct action on "hot" repositories as I'm still new and like to prevent any damages.
Sensible.
Regards,
Jeremiah
Quoting Jeremiah C. Foster (2021-10-06 22:22:55)
These repo groupings (core and packages) likely no longer serve the same purpose as originally - namely to be "complete and corresponding" source code for all the packages in PureOS. We likely ought to have a plan or create one for how we can have a one-to-one correspondence between source code in a git repo and the binaries in the archives to make support easier.
How will such change happen? How to know if it won't happen?
- Jonas
On 10/6/21 7:47 PM, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2021-10-06 22:22:55)
These repo groupings (core and packages) likely no longer serve the same purpose as originally - namely to be "complete and corresponding" source code for all the packages in PureOS. We likely ought to have a plan or create one for how we can have a one-to-one correspondence between source code in a git repo and the binaries in the archives to make support easier.
How will such change happen?
I don't know the details. I do know there has been very preliminary discussion on using git and existing tooling together in an approach like we do for the Librem 5 development. For work there, we tag packages, use a gitlab-ci.yml set up, and build on Jenkins. I believe the plan is to replace Jenkins or perhaps it's more accurate to say bypass Jenkins and send packages directly to Laniakea. Caveat emptor! I don't know the details or where we are.
How to know if it won't happen?
Hard to say because it already hasn't happened. :-)
- Jonas
Cheers,
Jeremiah
Quoting Jeremiah C. Foster (2021-10-07 02:47:57)
On 10/6/21 7:47 PM, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2021-10-06 22:22:55)
These repo groupings (core and packages) likely no longer serve the same purpose as originally - namely to be "complete and corresponding" source code for all the packages in PureOS. We likely ought to have a plan or create one for how we can have a one-to-one correspondence between source code in a git repo and the binaries in the archives to make support easier.
How will such change happen?
I don't know the details. I do know there has been very preliminary discussion on using git and existing tooling together in an approach like we do for the Librem 5 development. For work there, we tag packages, use a gitlab-ci.yml set up, and build on Jenkins. I believe the plan is to replace Jenkins or perhaps it's more accurate to say bypass Jenkins and send packages directly to Laniakea. Caveat emptor! I don't know the details or where we are.
Sorry, I was unclear: My question was about decision, not technical implementation.
Let me try again:
I have heard several times that the organisation of packages in the PureOS team had meaning historically and likely have less or no meaning nowadays.
My question is how do the PureOS transition from "likely ought to have a plan or create one" to "has a plan" on this matter?
How to know if it won't happen?
Hard to say because it already hasn't happened. :-)
Again, sorry for my ambiguity - let me try again:
How can Purism in general recognize if the PureOS team a) is in the process of transitioning from wanting a plan to having one or b) not being in such process.
(Obvisouly if one day the PureOS team announces "this is our plan!" there is no doubt, but if the PureOS team stops wanting a (new) plan then that is indistinguishable to being in the process of getting one.)
Kind regards,
- Jonas
Am 06.10.21 um 22:22 schrieb Jeremiah C. Foster: ...
Well, the thing is still, there is no branch I can start a MR against (at least I think). There is not even yet a tag 2.93 on soure.p.s., there is currently only the old master branch which isn't connected anyhow to the "mother" tree on Salsa.
This is an issue with all packages on source.puri.sm - both pureos/core and pureos/packages are not connected to Salsa or to Laniakea.
I think at the time PureOS was created it was the logical thing to do it that way to get things started. So no big thing and nobody to blame for anything. The project has grown and some things or workflows doesn't scale well now anymore.
These repo groupings (core and packages) likely no longer serve the same purpose as originally - namely to be "complete and corresponding" source code for all the packages in PureOS. We likely ought to have a plan or create one for how we can have a one-to-one correspondence between source code in a git repo and the binaries in the archives to make support easier.
As done in other territories mostly also in different context, I believe it's always a good idea to automate the stupid and boring things, like syncing the ongoing work in Debian / Salsa which is the base for PureOS or packaging building and do the QS on these.
So yes, building a new plan or at least adjusting an existing plan is obviously the way to go.
I haven't a complete overview of other packages like localechooser, but I expect there are more derived Debian packages which have a similar situation. My current plan was to go through sync issues in landing and work on the packages.
So it might be a good idea to think now how the amount of work to update and formalize all of these package should be done instead of doing a lot of manual steps that are different only on a small subset.
A first set of ideas...
We set up a mirroring of at least the relevant branches (and tags) from Salsa, that decreases additional work of adding locally the Salsa remote and pulling update from there.
Subsequently renaming PureOS related packaging branches to "pureos/" (localechooser uses currently "master" which is the same name as used on Salsa so syncing isn't possible).
In a long term there should be no big difference on core-packages and (pureos-)packages. But the current organization and structure on source.p.s might help the various teams to keep their overview.
On 10/7/21 5:10 AM, Carsten Schoenert wrote:
Am 06.10.21 um 22:22 schrieb Jeremiah C. Foster: ...
Well, the thing is still, there is no branch I can start a MR against (at least I think). There is not even yet a tag 2.93 on soure.p.s., there is currently only the old master branch which isn't connected anyhow to the "mother" tree on Salsa.
This is an issue with all packages on source.puri.sm - both pureos/core and pureos/packages are not connected to Salsa or to Laniakea.
I think at the time PureOS was created it was the logical thing to do it that way to get things started. So no big thing and nobody to blame for anything. The project has grown and some things or workflows doesn't scale well now anymore.
Absolutely. And I should have maybe used different words so that I didn't sound like I was blaming anyone, because that is not my intention.
These repo groupings (core and packages) likely no longer serve the same purpose as originally - namely to be "complete and corresponding" source code for all the packages in PureOS. We likely ought to have a plan or create one for how we can have a one-to-one correspondence between source code in a git repo and the binaries in the archives to make support easier.
As done in other territories mostly also in different context, I believe it's always a good idea to automate the stupid and boring things, like syncing the ongoing work in Debian / Salsa which is the base for PureOS or packaging building and do the QS on these.
+1
So yes, building a new plan or at least adjusting an existing plan is obviously the way to go.
+1
I haven't a complete overview of other packages like localechooser, but I expect there are more derived Debian packages which have a similar situation. My current plan was to go through sync issues in landing and work on the packages.
Much appreciated.
So it might be a good idea to think now how the amount of work to update and formalize all of these package should be done instead of doing a lot of manual steps that are different only on a small subset.
This seems wise.
A first set of ideas...
We set up a mirroring of at least the relevant branches (and tags) from Salsa, that decreases additional work of adding locally the Salsa remote and pulling update from there.
+1
Subsequently renaming PureOS related packaging branches to "pureos/" (localechooser uses currently "master" which is the same name as used on Salsa so syncing isn't possible).
Shall we use "pureos/latest"?
In a long term there should be no big difference on core-packages and (pureos-)packages. But the current organization and structure on source.p.s might help the various teams to keep their overview.
Agreed.
Thanks Carsten.
Jeremiah
Jeremiah,
Am 08.10.21 um 03:43 schrieb Jeremiah C. Foster:
Absolutely. And I should have maybe used different words so that I didn't sound like I was blaming anyone, because that is not my intention.
it was not my intention to say in some way that you would have blamed $someone, no absolutely not! I was simply trying to say that there are always reasons why people in the past have decided things to do in way we today wouldn't do.
...
Subsequently renaming PureOS related packaging branches to "pureos/" (localechooser uses currently "master" which is the same name as used on Salsa so syncing isn't possible).
Shall we use "pureos/latest"?
I'd say so, and it's the current practice already. That's the idea behind DEP14, "pureos" is the vendor namespace and "latest" is the most recent version which gets into right landing now.
-
Carsten Schoenert -
Jeremiah C. Foster -
Jonas Smedegaard