Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Tue, Jan 25, 2022 at 11:22:50AM +, Stuart Henderson wrote: > On 2022/01/24 19:11, Dima Pasechnik wrote: > > On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: > > > On 2022/01/24 15:51, Dima Pasechnik wrote: > > > > Would a git-generated email with a diff be acceptable? > > > > https://git-send-email.io/ > > > > > > Yes as long as it's not one of those big [1/n] sequences of separate > > > emails that would be better dealt with in a single mail :) > > > > > > > In principle, such a patch would be very easy to apply (with git) > > > > to your local git repo - and it can be bounced to appropriately > > > > configured CI... > > > > > > Applying it with git isn't useful for someone who is going to commit > > > it to cvs because (even if they use a mixture of git/got+cvs themselves) > > > it still needs to get into their cvs checkout. > > > > I'm guessing here, but can't you overlay CVS and git trees? > > If it's possible then merging with git will produce a CVS diff. > > While you can sort-of do that for the odd directory, you can't do that > for a whole tree, updates won't work. And git doesn't allow partial > checkouts/updates. > > (this is one of the biggest problems I would have with any change to > using git in the ports tree actually; if I am working on a port which > has received a change since my last work, I want to be able to just > fix conflicts in the directories I care about and _not_ be messing > with the whole rest of the tree at that time). Working on some kind of semi-updated tree, yuck. I think that outlines one of big CVS hiccups pretty well, for I really cannot see how this can be a problem if working with git, as updates would just merge nicely in git. > > > > What would you propose a CI to do for ports submissions? > > > > building (maybe testing too) the new/updated port only, just on amd64, as a > > start. > > That's not amazingly useful as the submitter already needed to build > it. They built it on their machine, not on something surely nice and clean. > And a test build of a port is going to require root access in > order to install dependencies which is not ideal for something where > a run can be triggered by a random submission. Why? It's run on something that is empherical. Another CI run would be in a new, clean environment, anyway. That's how modern CI works. Best Dima >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/26 17:41, Damien Miller wrote: > On Fri, 21 Jan 2022, joshua stein wrote: > > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > > > Maybe we can do something radical like enable GitHub pull requests > > to let people submit changes against the ports repo on GitHub, do > > review and feedback on those on GitHub, and once it's been approved > > by a developer, that developer can do the final legwork of > > committing it to CVS and closing the pull request (since we can't > > commit directly to the Git repo). > > I'm late to the party (as usual), but we've been doing this for a while > in OpenSSH - we'll review pull requests on github and have one of the > developers do the final tidying and commit to CVS. I can certainly see this working for some areas of OpenBSD. Especially more defined areas where primarily a smaller group of people handle most diffs going in, and where the mechanics of getting something committed account for a small part of the overall time taken to handle a submission. i.e. a higher % of the overall time is taken for review etc than with the mechanics of committing than is often the case for ports. In particular I think it's the case for OpenSSH where the vast majority of people using it are not OpenBSD users at all. > It's worked pretty well, and the quality of submissions is about as > good as we get from other outside sources. I believe it's allowed > a number of people who would otherwise not have contributed to do so, > since the tools are familiar and the hassle factor is so much lower. Ports by its nature needs domain-specific knowledge to successfully prepare an update. Nothing difficult, just some things to learn and do. Things like bumping revision numbers when changes are made, regenerating plists to pick up new files, looking for ABI changes in shared libraries, working on -current. In the context of that, putting the diff in an email rather than in a github PR isn't a high extra hurdle,
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, 21 Jan 2022, joshua stein wrote: > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). I'm late to the party (as usual), but we've been doing this for a while in OpenSSH - we'll review pull requests on github and have one of the developers do the final tidying and commit to CVS. It's worked pretty well, and the quality of submissions is about as good as we get from other outside sources. I believe it's allowed a number of people who would otherwise not have contributed to do so, since the tools are familiar and the hassle factor is so much lower. -d
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Tue, Jan 25, 2022 at 04:42:28AM +, Yifei Zhan wrote: > However I'm more concerned about the mailing part of the process, > since problems in it can't be easily detected on sender's machine > (some mailhosters would mangle inline patches when sending to other > hosts (Protonmail once had this problem, not sure if they fixed it > now)), and there is no undo botton for this list. > I remember setting up my email client was a PITA and Thunderbird would > mangle my patch no matter what, solene@ helped me testing my patch > many times until the whole setup finally worked. > Perhaps there can be a loopback address e.g. test-loopb...@openbsd.org > which just check if the patch can be applied and not mangled. Send it to yourself through your mailer. Use the patch you receive. If it doesn't work, don't send it to the lists, keep fixing your email client. I can't take credit for this idea, stsp@ mentioned it in his talk about device driver development. --Kurt
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Tue, Jan 25, 2022, at 4:36 AM, Stuart Henderson wrote: > On 2022/01/24 11:42, Aaron Bieber wrote: >> Another issue is having a ports tree in the "runner".. a git checkout is >> large, but maybe since it would be "local" to github it wouldn't be >> _that_ bad?.. but a cvs checkout would be way to slow. > > A cvs checkout of the ports tree from anoncvs over my home internet > connection takes 3 minutes. In that case the client is an 8 year old > machine with SATA SSD, server HDD (though the tree is probably mostly > in cache on the server). > > I don't think is _way_ too slow when a build could easily take hours > and often 10-20 minutes. > > On a better connected machine that should be at least a bit better too. > > btw git clone from github on the same client machine takes about 5 > minutes. Now try from github infra to github infra - I haven’t done any tests but I bet it’s faster than going over the internet. cvs checkout does use less disk space though.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/25 05:10, Yifei Zhan wrote: > > Another issue is having a ports tree in the "runner".. a git checkout is > > large, but maybe since it would be "local" to github it wouldn't be > > _that_ bad?.. but a cvs checkout would be way to slow. > > I think checking out a fresh git tree is alright, but we can only have > ~8G of usable space for building. Should be enough for smaller ports, > but unsure about the larger ones... That is not enough space to install dependencies for some medium sized ports, let alone build them.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/24 11:42, Aaron Bieber wrote: > Another issue is having a ports tree in the "runner".. a git checkout is > large, but maybe since it would be "local" to github it wouldn't be > _that_ bad?.. but a cvs checkout would be way to slow. A cvs checkout of the ports tree from anoncvs over my home internet connection takes 3 minutes. In that case the client is an 8 year old machine with SATA SSD, server HDD (though the tree is probably mostly in cache on the server). I don't think is _way_ too slow when a build could easily take hours and often 10-20 minutes. On a better connected machine that should be at least a bit better too. btw git clone from github on the same client machine takes about 5 minutes.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/24 19:11, Dima Pasechnik wrote: > On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: > > On 2022/01/24 15:51, Dima Pasechnik wrote: > > > Would a git-generated email with a diff be acceptable? > > > https://git-send-email.io/ > > > > Yes as long as it's not one of those big [1/n] sequences of separate > > emails that would be better dealt with in a single mail :) > > > > > In principle, such a patch would be very easy to apply (with git) > > > to your local git repo - and it can be bounced to appropriately > > > configured CI... > > > > Applying it with git isn't useful for someone who is going to commit > > it to cvs because (even if they use a mixture of git/got+cvs themselves) > > it still needs to get into their cvs checkout. > > I'm guessing here, but can't you overlay CVS and git trees? > If it's possible then merging with git will produce a CVS diff. While you can sort-of do that for the odd directory, you can't do that for a whole tree, updates won't work. And git doesn't allow partial checkouts/updates. (this is one of the biggest problems I would have with any change to using git in the ports tree actually; if I am working on a port which has received a change since my last work, I want to be able to just fix conflicts in the directories I care about and _not_ be messing with the whole rest of the tree at that time). > > What would you propose a CI to do for ports submissions? > > building (maybe testing too) the new/updated port only, just on amd64, as a > start. That's not amazingly useful as the submitter already needed to build it. And a test build of a port is going to require root access in order to install dependencies which is not ideal for something where a run can be triggered by a random submission.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Hi all, Re: fresh blood Can name you quite a few contributors that can be committers today, because they are demoin'g constant input to the project: 1) Caspar Schutijser 2) Wen Heping 3) Dimitri Karamazov There will be still some others I missed but the regular port committers will know, because you commit their contributions. There is nobody to propose for them. Thanks On Fri, Jan 21, 2022 at 11:31 AM Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > We have chronically fewer people who can give okays than ports waiting. > > One big "meta" stuff that needs doing is pointing out (especially from > new guys) what can be improved in the documentation of the porting process... > sometimes pointing people in the right direction. > > Informal poll: what thing weirded you guys out the first time you touched > OpenBSD ports coming from other platforms. > > What kind of gotcha can we get rid of, so that "new ports" will tend to > be squeaky clean, infrastructure-wise, and ready for import. > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > main differences to (say) deb, rpm, freebsd ?... >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Dima Pasechnik writes: > On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: >> On 2022/01/24 15:51, Dima Pasechnik wrote: >> > Would a git-generated email with a diff be acceptable? >> > https://git-send-email.io/ >> >> Yes as long as it's not one of those big [1/n] sequences of separate >> emails that would be better dealt with in a single mail :) >> >> > In principle, such a patch would be very easy to apply (with git) >> > to your local git repo - and it can be bounced to appropriately configured >> > CI... >> >> Applying it with git isn't useful for someone who is going to commit >> it to cvs because (even if they use a mixture of git/got+cvs themselves) >> it still needs to get into their cvs checkout. > > I'm guessing here, but can't you overlay CVS and git trees? > If it's possible then merging with git will produce a CVS diff. > >> >> > > At the moment it's hidden in a page named 'Building the System from >> > > Source', not very clear. Maybe put in on porter's handbook? >> > > >> > > - Some kind of automated pre-submission sanity test would be nice. >> > > Should be simpler than a full CI setup. (is my diff mangled? is my >> > > tree outdated?) >> > The OpenBSD-supporting CI I mentioned in my other email >> > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd >> > would be very easy to set up for this. >> >> What would you propose a CI to do for ports submissions? > > building (maybe testing too) the new/updated port only, just on amd64, as a > start. > > Dima My thought on this is basically: cd /usr/ports/thing/thatchanged && \ portcheck && \ make FETHC_PACKAGES= Also as far as CI "runners" go, this one looks promising: https://github.com/mario-campos/emulate Obviously 7.0 wouldn't be sufficient to do ports testing, but maybe current could be added without much hassle. Another issue is having a ports tree in the "runner".. a git checkout is large, but maybe since it would be "local" to github it wouldn't be _that_ bad?.. but a cvs checkout would be way to slow. > >> >> Identifying and building ports that depend on a particular port and >> doing a build of all of them on a clean -current OpenBSD system could >> be useful in some cases, though complete overkill in most, and would >> take long enough that it would be silly to do before a basic review. >> >> There's another consideration with this. In a way it's good if a diff >> from a less-experienced porter has some easier-to-spot issues (i.e. >> the sort of issues that an automated check would be likely to identify) >> because it's a bit of a flag that other, harder to spot, issues are >> likely to be present too. >>
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: > On 2022/01/24 15:51, Dima Pasechnik wrote: > > Would a git-generated email with a diff be acceptable? > > https://git-send-email.io/ > > Yes as long as it's not one of those big [1/n] sequences of separate > emails that would be better dealt with in a single mail :) > > > In principle, such a patch would be very easy to apply (with git) > > to your local git repo - and it can be bounced to appropriately configured > > CI... > > Applying it with git isn't useful for someone who is going to commit > it to cvs because (even if they use a mixture of git/got+cvs themselves) > it still needs to get into their cvs checkout. I'm guessing here, but can't you overlay CVS and git trees? If it's possible then merging with git will produce a CVS diff. > > > > At the moment it's hidden in a page named 'Building the System from > > > Source', not very clear. Maybe put in on porter's handbook? > > > > > > - Some kind of automated pre-submission sanity test would be nice. > > > Should be simpler than a full CI setup. (is my diff mangled? is my > > > tree outdated?) > > The OpenBSD-supporting CI I mentioned in my other email > > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd > > would be very easy to set up for this. > > What would you propose a CI to do for ports submissions? building (maybe testing too) the new/updated port only, just on amd64, as a start. Dima > > Identifying and building ports that depend on a particular port and > doing a build of all of them on a clean -current OpenBSD system could > be useful in some cases, though complete overkill in most, and would > take long enough that it would be silly to do before a basic review. > > There's another consideration with this. In a way it's good if a diff > from a less-experienced porter has some easier-to-spot issues (i.e. > the sort of issues that an automated check would be likely to identify) > because it's a bit of a flag that other, harder to spot, issues are > likely to be present too. >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/24 15:51, Dima Pasechnik wrote: > Would a git-generated email with a diff be acceptable? > https://git-send-email.io/ Yes as long as it's not one of those big [1/n] sequences of separate emails that would be better dealt with in a single mail :) > In principle, such a patch would be very easy to apply (with git) > to your local git repo - and it can be bounced to appropriately configured > CI... Applying it with git isn't useful for someone who is going to commit it to cvs because (even if they use a mixture of git/got+cvs themselves) it still needs to get into their cvs checkout. > > At the moment it's hidden in a page named 'Building the System from > > Source', not very clear. Maybe put in on porter's handbook? > > > > - Some kind of automated pre-submission sanity test would be nice. > > Should be simpler than a full CI setup. (is my diff mangled? is my > > tree outdated?) > The OpenBSD-supporting CI I mentioned in my other email > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd > would be very easy to set up for this. What would you propose a CI to do for ports submissions? Identifying and building ports that depend on a particular port and doing a build of all of them on a clean -current OpenBSD system could be useful in some cases, though complete overkill in most, and would take long enough that it would be silly to do before a basic review. There's another consideration with this. In a way it's good if a diff from a less-experienced porter has some easier-to-spot issues (i.e. the sort of issues that an automated check would be likely to identify) because it's a bit of a flag that other, harder to spot, issues are likely to be present too.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:49:26PM +, Yifei Zhan wrote: > On 22/01/22 02:30AM, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > > > Volker Schlecht writes: > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend > > > > > to > > > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > An FAQ of sorts might *help*, particularly one addressing the more > > > > typical beginner mistakes. What are the things that you guys > > > > immediately > > > > look out for when a new name offers up a diff because they're usually > > > > done wrong? > > > > > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > > > suggestions and improvements including possibly large-scale rewriting... > > > Feel free to send a diff for it to ports@. > > > > > > > > Any kind of pointers (including diffs to manpages or whatever) that > > would make it easier for newcomers to find that > > would be a great addition to the system. > > > > Especially from "newer" people who have been figuring it out. > > > > Us old-timers have about ZERO idea what's actually needed. > > > > Some ideas: > > - How to find LIBDEP: > https://marc.info/?l=openbsd-ports=164089356505525=2 > > - A simple CVS quick start guide would be nice, I spent way too long > to learn it and I'm still not totally sure how it works. (e.g. how to > generate a diff properly/how to apply an inline patch/how to handle > new directory...etc) > > yes there are countless guides alrealy on the internet, but most of > them are confusing and not really suitable for OpenBSD's workflow. > > and since we are here, what's your workflow of testing/generating > diff? often I would corrupt my ports tree while testing/generating > diff and have to check out a fresh copy) > > - Make it more clear that git generated diff is acceptable Would a git-generated email with a diff be acceptable? https://git-send-email.io/ In principle, such a patch would be very easy to apply (with git) to your local git repo - and it can be bounced to appropriately configured CI... > > At the moment it's hidden in a page named 'Building the System from > Source', not very clear. Maybe put in on porter's handbook? > > - Some kind of automated pre-submission sanity test would be nice. > Should be simpler than a full CI setup. (is my diff mangled? is my > tree outdated?) The OpenBSD-supporting CI I mentioned in my other email https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd would be very easy to set up for this. Dima
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:49:26PM +, Yifei Zhan wrote: > On 22/01/22 02:30AM, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > > > Volker Schlecht writes: > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend > > > > > to > > > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > An FAQ of sorts might *help*, particularly one addressing the more > > > > typical beginner mistakes. What are the things that you guys > > > > immediately > > > > look out for when a new name offers up a diff because they're usually > > > > done wrong? > > > > > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > > > suggestions and improvements including possibly large-scale rewriting... > > > Feel free to send a diff for it to ports@. > > > > > > > > Any kind of pointers (including diffs to manpages or whatever) that > > would make it easier for newcomers to find that > > would be a great addition to the system. > > > > Especially from "newer" people who have been figuring it out. > > > > Us old-timers have about ZERO idea what's actually needed. > > > > Some ideas: > > - How to find LIBDEP: > https://marc.info/?l=openbsd-ports=164089356505525=2 > There's some supplementary work I need to do in port-lib-depends, namely interface it with the pkglocatedb so that missing dependencies can be located more easily. Also, yeah, that code is rather hard to read, I know. > - A simple CVS quick start guide would be nice, I spent way too long > to learn it and I'm still not totally sure how it works. (e.g. how to > generate a diff properly/how to apply an inline patch/how to handle > new directory...etc) It's a complete pain in the ass in any case. > yes there are countless guides alrealy on the internet, but most of > them are confusing and not really suitable for OpenBSD's workflow. > > and since we are here, what's your workflow of testing/generating > diff? often I would corrupt my ports tree while testing/generating > diff and have to check out a fresh copy) > > - Make it more clear that git generated diff is acceptable Yeah, that's a really good point. > At the moment it's hidden in a page named 'Building the System from > Source', not very clear. Maybe put in on porter's handbook? > > - Some kind of automated pre-submission sanity test would be nice. > Should be simpler than a full CI setup. (is my diff mangled? is my > tree outdated?) > You got portcheck for that one. It does validate new ports and ports after diff. Notice that https://www.openbsd.org/faq/index.html contains a Porter's handbook and a Port Testing guide. If those are not apparent enough, diffs are welcome. If things are missing in there, again, diffs are welcome.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:39:50PM +0100, Dima Pasechnik wrote: > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > > In my opinion, our main issue is the lack of new blood. > > > > > > We have chronically fewer people who can give okays than ports waiting. > > > > > > One big "meta" stuff that needs doing is pointing out (especially from > > > new guys) what can be improved in the documentation of the porting > > > process... > > > sometimes pointing people in the right direction. > > > > > > Informal poll: what thing weirded you guys out the first time you touched > > > OpenBSD ports coming from other platforms. > > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > > main differences to (say) deb, rpm, freebsd ?... > > > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > > > Maybe we can do something radical like enable GitHub pull requests > > to let people submit changes against the ports repo on GitHub, do > > review and feedback on those on GitHub, and once it's been approved > > by a developer, that developer can do the final legwork of > > committing it to CVS and closing the pull request (since we can't > > commit directly to the Git repo). > > > I read this, and the whole following thread, and noone mentioned CI > (continuous integration) > - something that made GitHub much more useful than merely a git server > hosting service. > > In a CI-enabled world, one could usually see the results of applying a diff, > and > building+testing, it's there, done for you, automatically. > Indeed, using GitHub's CI with OpenBSD is tricky (if possible at all), but > fortunately We got a framework for bulk-building ports: dpb(1) That's the whole integration we get... the full ports tree is generally rebuilt every few days (or weeks) or supported architectures. Good luck getting a proper infrastructure off the ground, especially on lesser known architectures. We do frown on cross-compilation for various reasons.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > > > We have chronically fewer people who can give okays than ports waiting. > > > > One big "meta" stuff that needs doing is pointing out (especially from > > new guys) what can be improved in the documentation of the porting > > process... > > sometimes pointing people in the right direction. > > > > Informal poll: what thing weirded you guys out the first time you touched > > OpenBSD ports coming from other platforms. > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). I read this, and the whole following thread, and noone mentioned CI (continuous integration) - something that made GitHub much more useful than merely a git server hosting service. In a CI-enabled world, one could usually see the results of applying a diff, and building+testing, it's there, done for you, automatically. Indeed, using GitHub's CI with OpenBSD is tricky (if possible at all), but fortunately there are other similar free services, such as one by Sourcehut: https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd Second point: I'd agree that GitHub is far from an ideal solution here, but the underlying tool, git, is certainly way more powerful than CVS. Hey, I used CVS a bit in 1999, and fogot all about it. Yes, CVS can be helped with extra tooling, but this kind of tooling is made largely obsolete by git. (The theme CVS vs Subversion vs git has certainly been explored in all the details on the net, I don't want to repeat it here.) Switching to git would certainly be very welcoming for newcomers. HTH Dima users.ox.ac.uk/~coml0531/ > > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > Volker Schlecht writes: > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > be squeaky clean, infrastructure-wise, and ready for import. > > An FAQ of sorts might *help*, particularly one addressing the more > > typical beginner mistakes. What are the things that you guys immediately > > look out for when a new name offers up a diff because they're usually > > done wrong? > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > suggestions and improvements including possibly large-scale rewriting... > Feel free to send a diff for it to ports@. > > Any kind of pointers (including diffs to manpages or whatever) that would make it easier for newcomers to find that would be a great addition to the system. Especially from "newer" people who have been figuring it out. Us old-timers have about ZERO idea what's actually needed.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 04:13:10PM -0500, Kurt Mosiejczuk wrote: > On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > > Volker Schlecht writes: > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > > be squeaky clean, infrastructure-wise, and ready for import. > > > An FAQ of sorts might *help*, particularly one addressing the more > > > typical beginner mistakes. What are the things that you guys immediately > > > look out for when a new name offers up a diff because they're usually > > > done wrong? > > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > > suggestions and improvements including possibly large-scale rewriting... > > Feel free to send a diff for it to ports@. > > Yes. Those of us well-versed in it are those most likely to miss putting > important details in the FAQ. > > --Kurt > This thread has some great tips in it: https://marc.info/?l=openbsd-ports=163950488420152=2 It deals with BUILD, RUN and TEST_DEPENDS and when to use what. -- Chris
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Am Fri, Jan 21, 2022 at 07:24:34PM +0100 schrieb Marc Espie: > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > > > Using CVS and dealing with tarballs is probably pretty > > > ancient-feeling for many outsiders. I don't know that more > > > documentation is really the problem. > > > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > > can easily view in my e-mail client because it's a hassle to save > > > the attachment, tar -t it to see what its directory structure is, > > > untar it in the proper place, try to build it, then provide feedback > > > by copying parts of the Makefile to an e-mail or doing some other > > > work to produce a diff. > > > > I never understood why new ports have to submitted as a tarball. > > Why not accept new ports as a diff which only creates new files? > > It is trivial to create such a diff. > > Give me the magical recipie that does NOT create directories in the actual > CVS repository/is usable without write access to the OpenBSD CVS repo or > a copy ! > > They DON'T create new files, they create NEW DIRECTORIES. > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > without a local repository! Sounds like a reason to ditch CVS and switch to git.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > Volker Schlecht writes: > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > be squeaky clean, infrastructure-wise, and ready for import. > > An FAQ of sorts might *help*, particularly one addressing the more > > typical beginner mistakes. What are the things that you guys immediately > > look out for when a new name offers up a diff because they're usually > > done wrong? > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > suggestions and improvements including possibly large-scale rewriting... > Feel free to send a diff for it to ports@. Yes. Those of us well-versed in it are those most likely to miss putting important details in the FAQ. --Kurt
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Volker Schlecht writes: > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > An FAQ of sorts might *help*, particularly one addressing the more > typical beginner mistakes. What are the things that you guys immediately > look out for when a new name offers up a diff because they're usually > done wrong? There's https://www.openbsd.org/faq/ports/ ; it's wide open for suggestions and improvements including possibly large-scale rewriting... Feel free to send a diff for it to ports@.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/21 11:42, joshua stein wrote: > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. this helps a lot: $ grep vim .mailcap application/x-tar; vim '%s' application/x-xz; vim '%s' application/x-tar-gz; vim '%s' application/x-gzip; vim '%s' application/gzip; vim '%s' application/x-gunzip; vim '%s' application/x-gtar; vim '%s' application/x-xz; vim '%s' application/x-gtar-compressed; vim '%s' application/x-compressed-tar; vim '%s' application/octet-stream; vim '%s' > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). No way. Way too much burden for regular ports committers. This takes the existing work, adds a bunch of extra steps required, and encourage submissions from people that aren't keeping on top of how OpenBSD works which are likely to add even more work for us.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 08:55:57PM +0100, Stefan Sperling wrote: > On Fri, Jan 21, 2022 at 08:44:14PM +0100, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 07:47:44PM +0100, Stefan Sperling wrote: > > > On Fri, Jan 21, 2022 at 07:24:34PM +0100, Marc Espie wrote: > > > > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > > > > I never understood why new ports have to submitted as a tarball. > > > > > Why not accept new ports as a diff which only creates new files? > > > > > It is trivial to create such a diff. > > > > > > > > Give me the magical recipie that does NOT create directories in the > > > > actual > > > > CVS repository/is usable without write access to the OpenBSD CVS repo or > > > > a copy ! > > > > > > > > They DON'T create new files, they create NEW DIRECTORIES. > > > > > > > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > > > > without a local repository! > > > > > > cvsdo can do it by faking new directories entries in CVS/Entries files. > > > This does not require adding directories to the repository (see below). > > > I am not suggesting this is a great solution, but it can be done. > > > > Is this documented anywhere for new people? > > I doubt it. > But before recommending this approach, a few people should try to work > through entire submissions of non-trivial ports with it. There might be > some gotchas which the trivial cases I've used this for cannot uncover. > I last used cvsdo years ago while submitting diffs for both src and ports, > and only in the rare cases where I had to add new files. > Nothing like tor-browser or chromium :P > > Nowadays, I would use devel/got to create such a diff against ports.git > cloned from github. But that is not CVS and it is probably too early to > generally recommend got instead of git to work on ports. Though I would > be happy to receive bug reports against got from interested ports devs. > I use a hybrid system of sorts. My ports tree is from CVS. My mystuff directory in my ports tree is got controlled. When I work on a port, the cvs directory is copied to mystuff and added to got. That way, I can track changes the way I am comfortable, adding and removing files from both got and CVS, etc. I can then generate diffs from either got or CVS, but this way it's easy for me to revert something in got if I need to. When finished, I can simply commit from this directory to CVS and update my ports tree, then remove from got. May sound weird, but it works for me and helps me keep things straight on some of the more complicated junk I work on, simultaneously keeping my github wip repo up-to-date, since mystuff is a bare clone from my github account. -- Tracey Emery
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 1/21/22 18:29, Marc Espie wrote: Informal poll: what thing weirded you guys out the first time you touched OpenBSD ports coming from other platforms. Wouldn't say it weirded me out, but it took me quite a while to create some sort of mental model about what's going on with everything involving WANTLIB. And I'm sure the one I have now is wrong ;) That and I don't know how often I've wiped my ports tree in the beginning because I accidentally used 'CVS up' with a 027 umask ... What kind of gotcha can we get rid of, so that "new ports" will tend to be squeaky clean, infrastructure-wise, and ready for import. An FAQ of sorts might *help*, particularly one addressing the more typical beginner mistakes. What are the things that you guys immediately look out for when a new name offers up a diff because they're usually done wrong? If you give *me* a list of common beginner's mistakes however, that just means that I'll make less common ones. I've yet to meet anyone for whom that's substantially different, so "squeaky clean" diffs from first timers may generally out of reach, no matter how great the documentation. As to the causes for the mistakes I made so far, I can however confirm that none of them were attributable to CVS or any part of the toolchain ;-p
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 08:44:14PM +0100, Marc Espie wrote: > On Fri, Jan 21, 2022 at 07:47:44PM +0100, Stefan Sperling wrote: > > On Fri, Jan 21, 2022 at 07:24:34PM +0100, Marc Espie wrote: > > > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > > > I never understood why new ports have to submitted as a tarball. > > > > Why not accept new ports as a diff which only creates new files? > > > > It is trivial to create such a diff. > > > > > > Give me the magical recipie that does NOT create directories in the actual > > > CVS repository/is usable without write access to the OpenBSD CVS repo or > > > a copy ! > > > > > > They DON'T create new files, they create NEW DIRECTORIES. > > > > > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > > > without a local repository! > > > > cvsdo can do it by faking new directories entries in CVS/Entries files. > > This does not require adding directories to the repository (see below). > > I am not suggesting this is a great solution, but it can be done. > > Is this documented anywhere for new people? I doubt it. But before recommending this approach, a few people should try to work through entire submissions of non-trivial ports with it. There might be some gotchas which the trivial cases I've used this for cannot uncover. I last used cvsdo years ago while submitting diffs for both src and ports, and only in the rare cases where I had to add new files. Nothing like tor-browser or chromium :P Nowadays, I would use devel/got to create such a diff against ports.git cloned from github. But that is not CVS and it is probably too early to generally recommend got instead of git to work on ports. Though I would be happy to receive bug reports against got from interested ports devs.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 07:47:44PM +0100, Stefan Sperling wrote: > On Fri, Jan 21, 2022 at 07:24:34PM +0100, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > > I never understood why new ports have to submitted as a tarball. > > > Why not accept new ports as a diff which only creates new files? > > > It is trivial to create such a diff. > > > > Give me the magical recipie that does NOT create directories in the actual > > CVS repository/is usable without write access to the OpenBSD CVS repo or > > a copy ! > > > > They DON'T create new files, they create NEW DIRECTORIES. > > > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > > without a local repository! > > cvsdo can do it by faking new directories entries in CVS/Entries files. > This does not require adding directories to the repository (see below). > I am not suggesting this is a great solution, but it can be done. Is this documented anywhere for new people?
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 01:12:05PM -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 16:06:00 -0300, Crystal Kolipe wrote: > > On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: > > > Here is my experience: http://www.oxide.org/cvs/abieber.html > > > > Wow, that server is slow. And doesn't even support https. > > So you want to enforce your "standard", I.E. https, on everybody? > > If we're going to have a "standard", why not make it the lowest > common denominator, so that people who are comfortable with browsing > with their own tools can easily handle it the way they want to? > Which is, basically, the whole unix philosophy anyway. Thankyou! I totally agree! And the lowest common denominator would be to post the content to the list, (or preferably to me personally and to stop spamming the list with off-topic drivel). That way I wouldn't have to fetch an external resource, be it over http or https or gopher, or whatever. Which was, ironically, one of my original rants about the proposed use of GitHub. Nevertheless, if you ARE going to post an external link, at least give people the OPTION of pulling it over https.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, 21 Jan 2022 at 16:06:00 -0300, Crystal Kolipe wrote: > On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: > > Here is my experience: http://www.oxide.org/cvs/abieber.html > > Wow, that server is slow. And doesn't even support https. So you want to enforce your "standard", I.E. https, on everybody? If we're going to have a "standard", why not make it the lowest common denominator, so that people who are comfortable with browsing with their own tools can easily handle it the way they want to? Which is, basically, the whole unix philosophy anyway.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Crystal Kolipe writes: > On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: >> Here is my experience: http://www.oxide.org/cvs/abieber.html > > Wow, that server is slow. And doesn't even support https. Alternatively - you could look through cvs history :)
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: > Here is my experience: http://www.oxide.org/cvs/abieber.html Wow, that server is slow. And doesn't even support https.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Crystal Kolipe writes: > On Fri, Jan 21, 2022 at 11:24:34AM -0700, Aaron Bieber wrote: >> >> Crystal Kolipe writes: >> >> > On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: >> >> "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know >> >> how to use tar. The problem is that people send things totally >> >> differently and there is no agreed upon "standard". GH would remedy this >> >> because everything would become a diff - plain text! >> > >> > So you want to enforce your "standard", I.E. GitHub, on everybody? >> > >> > If we're going to have a "standard", why not make it the lowest common >> > denominator, so that people who are comfortable with creating their own >> > tools can easily handle it the way they want to? Which is, basically, >> > the whole unix philosophy anyway. >> > >> >> Also if people don't want to use the GH approach - they don't have to! >> > >> > But the use of GitHub would become like a virus, in that it also affects >> > people who don't want to use it. >> > >> >> at no point did jcs suggest that we make everyone get a GH account and >> >> switch to using it exclusively. >> > >> > Go and read the Linux kernel archives from 20 years ago, and the flamewars >> > over the use of BitKeeper to manage the kernel source. >> >> I don't even know how to respond to this. You are saying that GH usage >> will infect people and then they will be forced to use it? > > Not really, no. > > I'm saying that once some people start using GitHub to automatically generate > diffs and send them to this mailing list, then the next step will likely be > that development starts moving off of the mailing list altogether, and only > accessible via a tedious pointy-clicky webbrowser interface, rather than as > free-format conversation on a mailing list, which has worked fine ever since > the OpenBSD project first began. > >> That seems a bit far fetched to me. But maybe that's the mindvirus at >> work! >> >> No idea what linux kernel archievs from 20 years ago have to do with any >> of this. > > Well, you've really answered your own question there. > I mean contextually with the conversation around openbsd, cvs and a new process. Obviously. > Do you even know why git was created? What came before it? I feel like you are trying to undermine my credibility with this statement. How much experience do you have committing things in OpenBSD with cvs? Here is my experience: http://www.oxide.org/cvs/abieber.html Maybe we should change the topic to "On the subject of non-OpenBSD developers opinions on the process of developing OpenBSD" :P
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 07:47:44PM +0100, Stefan Sperling wrote: > cvsdo can do it by faking new directories entries in CVS/Entries files. > This does not require adding directories to the repository (see below). > I am not suggesting this is a great solution, but it can be done. For those playing at home, cvsdo is in the super-useful cvsutils package. --Kurt > $ ls /tmp/repo/ > CVSROOT/ test/ > $ cvs -d /tmp/repo co -P test > cvs checkout: Updating test > U test/alpha > $ cd test > $ mkdir foo > $ cvsdo add foo > $ echo 'hello world' > foo/new > $ cvsdo add foo/new > $ cvs -R diff -uNp foo > cvs diff: Diffing foo > Index: foo/new > === > RCS file: foo/new > diff -N foo/new > --- /dev/null 1 Jan 1970 00:00:00 - > +++ foo/new 21 Jan 2022 18:38:57 - > @@ -0,0 +1 @@ > +hello world > $ mkdir foo/patches > $ echo new patch > foo/patches/patch1 > $ cvsdo add foo/patches/patch1 > $ cvs -R diff -uNp foo foo/patches > cvs diff: Diffing foo > Index: foo/new > === > RCS file: foo/new > diff -N foo/new > --- /dev/null 1 Jan 1970 00:00:00 - > +++ foo/new 21 Jan 2022 18:38:57 - > @@ -0,0 +1 @@ > +hello world > cvs diff: Diffing foo/patches > Index: foo/patches/patch1 > === > RCS file: foo/patches/patch1 > diff -N foo/patches/patch1 > --- /dev/null 1 Jan 1970 00:00:00 - > +++ foo/patches/patch1 21 Jan 2022 18:41:50 - > @@ -0,0 +1 @@ > +new patch > $ ls /tmp/repo/test/ > alpha,v > $ >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 07:24:34PM +0100, Marc Espie wrote: > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > I never understood why new ports have to submitted as a tarball. > > Why not accept new ports as a diff which only creates new files? > > It is trivial to create such a diff. > > Give me the magical recipie that does NOT create directories in the actual > CVS repository/is usable without write access to the OpenBSD CVS repo or > a copy ! > > They DON'T create new files, they create NEW DIRECTORIES. > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > without a local repository! cvsdo can do it by faking new directories entries in CVS/Entries files. This does not require adding directories to the repository (see below). I am not suggesting this is a great solution, but it can be done. $ ls /tmp/repo/ CVSROOT/ test/ $ cvs -d /tmp/repo co -P test cvs checkout: Updating test U test/alpha $ cd test $ mkdir foo $ cvsdo add foo $ echo 'hello world' > foo/new $ cvsdo add foo/new $ cvs -R diff -uNp foo cvs diff: Diffing foo Index: foo/new === RCS file: foo/new diff -N foo/new --- /dev/null 1 Jan 1970 00:00:00 - +++ foo/new 21 Jan 2022 18:38:57 - @@ -0,0 +1 @@ +hello world $ mkdir foo/patches $ echo new patch > foo/patches/patch1 $ cvsdo add foo/patches/patch1 $ cvs -R diff -uNp foo foo/patches cvs diff: Diffing foo Index: foo/new === RCS file: foo/new diff -N foo/new --- /dev/null 1 Jan 1970 00:00:00 - +++ foo/new 21 Jan 2022 18:38:57 - @@ -0,0 +1 @@ +hello world cvs diff: Diffing foo/patches Index: foo/patches/patch1 === RCS file: foo/patches/patch1 diff -N foo/patches/patch1 --- /dev/null 1 Jan 1970 00:00:00 - +++ foo/patches/patch1 21 Jan 2022 18:41:50 - @@ -0,0 +1 @@ +new patch $ ls /tmp/repo/test/ alpha,v $
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:24:34AM -0700, Aaron Bieber wrote: > > Crystal Kolipe writes: > > > On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: > >> "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know > >> how to use tar. The problem is that people send things totally > >> differently and there is no agreed upon "standard". GH would remedy this > >> because everything would become a diff - plain text! > > > > So you want to enforce your "standard", I.E. GitHub, on everybody? > > > > If we're going to have a "standard", why not make it the lowest common > > denominator, so that people who are comfortable with creating their own > > tools can easily handle it the way they want to? Which is, basically, > > the whole unix philosophy anyway. > > > >> Also if people don't want to use the GH approach - they don't have to! > > > > But the use of GitHub would become like a virus, in that it also affects > > people who don't want to use it. > > > >> at no point did jcs suggest that we make everyone get a GH account and > >> switch to using it exclusively. > > > > Go and read the Linux kernel archives from 20 years ago, and the flamewars > > over the use of BitKeeper to manage the kernel source. > > I don't even know how to respond to this. You are saying that GH usage > will infect people and then they will be forced to use it? Not really, no. I'm saying that once some people start using GitHub to automatically generate diffs and send them to this mailing list, then the next step will likely be that development starts moving off of the mailing list altogether, and only accessible via a tedious pointy-clicky webbrowser interface, rather than as free-format conversation on a mailing list, which has worked fine ever since the OpenBSD project first began. > That seems a bit far fetched to me. But maybe that's the mindvirus at > work! > > No idea what linux kernel archievs from 20 years ago have to do with any > of this. Well, you've really answered your own question there. Do you even know why git was created? What came before it?
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Crystal Kolipe writes: > On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: >> "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know >> how to use tar. The problem is that people send things totally >> differently and there is no agreed upon "standard". GH would remedy this >> because everything would become a diff - plain text! > > So you want to enforce your "standard", I.E. GitHub, on everybody? > > If we're going to have a "standard", why not make it the lowest common > denominator, so that people who are comfortable with creating their own > tools can easily handle it the way they want to? Which is, basically, > the whole unix philosophy anyway. > >> Also if people don't want to use the GH approach - they don't have to! > > But the use of GitHub would become like a virus, in that it also affects > people who don't want to use it. > >> at no point did jcs suggest that we make everyone get a GH account and >> switch to using it exclusively. > > Go and read the Linux kernel archives from 20 years ago, and the flamewars > over the use of BitKeeper to manage the kernel source. I don't even know how to respond to this. You are saying that GH usage will infect people and then they will be forced to use it? That seems a bit far fetched to me. But maybe that's the mindvirus at work! No idea what linux kernel archievs from 20 years ago have to do with any of this.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > I never understood why new ports have to submitted as a tarball. > Why not accept new ports as a diff which only creates new files? > It is trivial to create such a diff. Give me the magical recipie that does NOT create directories in the actual CVS repository/is usable without write access to the OpenBSD CVS repo or a copy ! They DON'T create new files, they create NEW DIRECTORIES. Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO without a local repository!
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > > > We have chronically fewer people who can give okays than ports waiting. > > > > One big "meta" stuff that needs doing is pointing out (especially from > > new guys) what can be improved in the documentation of the porting > > process... > > sometimes pointing people in the right direction. > > > > Informal poll: what thing weirded you guys out the first time you touched > > OpenBSD ports coming from other platforms. > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. We could have some kind of script that checks the directory structure of a tarball AND explicitly ask that new ports are tarballs that are based under ports (or maybe have a script that packages new ports for that). Doing "full diffs" for new ports under CVS is 100% a pain in the butt: you either have to have a CVS mirror locally, and add directories in there, OR you must create directories before-hand for that on the "real" repository CVS SUCKS THAT WAY BIG TIME. (I haven't said this loud enough) CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). We have have git diff format support in our patch for a while. I'm pretty sure I *DO NOT WANT* automated stuff between github and this mailing list. That said, instructions on - where the "official" github mirror is - how to clone it and possibly: - directions/scripts on how to prepare a submission from there to here might be a good idea.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
I have to say no also to this idea. While using Github separately for working on a particular group of ports with a few others is fine, having 12 WIP ports would make a real mess. For example, portgen with Perl makes a cpan directory with a good, but very flawed start on a port, usually with quite a few new dependencies. These would also need to go up into the tree for future work, by myself or someday by others. Some people put a new or updated port into devel or other category. I put mine into mystuff in order to get a fresh tree, but keep my work on a separate partition and safe. The mountain of email messages I get from Github requires a different email to endure it. -- Chris Bennett
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: > "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know > how to use tar. The problem is that people send things totally > differently and there is no agreed upon "standard". GH would remedy this > because everything would become a diff - plain text! So you want to enforce your "standard", I.E. GitHub, on everybody? If we're going to have a "standard", why not make it the lowest common denominator, so that people who are comfortable with creating their own tools can easily handle it the way they want to? Which is, basically, the whole unix philosophy anyway. > Also if people don't want to use the GH approach - they don't have to! But the use of GitHub would become like a virus, in that it also affects people who don't want to use it. > at no point did jcs suggest that we make everyone get a GH account and > switch to using it exclusively. Go and read the Linux kernel archives from 20 years ago, and the flamewars over the use of BitKeeper to manage the kernel source.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Crystal Kolipe writes: > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: >> Maybe we can do something radical like enable GitHub pull requests >> to let people submit changes against the ports repo on GitHub > > Cringe. > > I sincerely hope that this doesn't happen. > > Just look at the typical quality of the projects hosted on GitHub, and > you'll see how relying on a set of third-party managed tools to do your > work instead of taking the time to learn the basic tools, (tar, diff, > an email program, etc), yourself can lead to laziness and poor quality. > > If people can't be bothered to do things themselves or make their own > tools to automate a process, how dedicated are they likely to be? > >> I believe that the GitHub repo can be configured to also email >> ports@openbsd.org on any submissions/comments there, so the mailing >> list would still be in the loop on everything for anyone that >> doesn't want to use GitHub. > > So the mailing list is going to be flooded with automated mails from > GitHub, that become tedious, leading people to just skim over them > or OK them without really reviewing the content. > > Honestly, I think we all want to keep the quality of the ports tree > as high as possible, and if learing to use tar and diff as a barrier to > entry for some people is doing that, I suggest we continue as we are. "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know how to use tar. The problem is that people send things totally differently and there is no agreed upon "standard". GH would remedy this because everything would become a diff - plain text! Also if people don't want to use the GH approach - they don't have to! at no point did jcs suggest that we make everyone get a GH account and switch to using it exclusively.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. I never understood why new ports have to submitted as a tarball. Why not accept new ports as a diff which only creates new files? It is trivial to create such a diff. Well, CVS makes it somewhat non-trivial for people without write access to the main repository, but not impossible. You could pkg_add cvsutils and use cvsdo add to make new files and directories appear (I have done this before, it works). Or you could add new directories against a local repository mirror and produce a diff against it. And of course there is the Git conversion on github. With a Git repository it is very trivial to create a diff which adds a new port. I don't think we would even need to explain how. People who become curious about OpenBSD development today will very likely already be comfortable with Git. Allowing pull requests has the downside that the mailing list cannot easily respond to what is going on at Github. Splitting the conversation across two disparate communiation channels won't work very well. Github tends to assume that it is the only place where all the action is.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub Cringe. I sincerely hope that this doesn't happen. Just look at the typical quality of the projects hosted on GitHub, and you'll see how relying on a set of third-party managed tools to do your work instead of taking the time to learn the basic tools, (tar, diff, an email program, etc), yourself can lead to laziness and poor quality. If people can't be bothered to do things themselves or make their own tools to automate a process, how dedicated are they likely to be? > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. So the mailing list is going to be flooded with automated mails from GitHub, that become tedious, leading people to just skim over them or OK them without really reviewing the content. Honestly, I think we all want to keep the quality of the ports tree as high as possible, and if learing to use tar and diff as a barrier to entry for some people is doing that, I suggest we continue as we are.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
joshua stein writes: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: >> In my opinion, our main issue is the lack of new blood. >> >> We have chronically fewer people who can give okays than ports waiting. >> >> One big "meta" stuff that needs doing is pointing out (especially from >> new guys) what can be improved in the documentation of the porting process... >> sometimes pointing people in the right direction. >> >> Informal poll: what thing weirded you guys out the first time you touched >> OpenBSD ports coming from other platforms. >> >> What kind of gotcha can we get rid of, so that "new ports" will tend to >> be squeaky clean, infrastructure-wise, and ready for import. >> >> Maybe we'd need an FAQ from people coming from elsewhere explaining the >> main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). > > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. This would be awesome! I bet we could even automate the closing after something was committed to CVS!
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 21/01/22 11:42 -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > > > We have chronically fewer people who can give okays than ports waiting. > > > > One big "meta" stuff that needs doing is pointing out (especially from > > new guys) what can be improved in the documentation of the porting > > process... > > sometimes pointing people in the right direction. > > > > Informal poll: what thing weirded you guys out the first time you touched > > OpenBSD ports coming from other platforms. > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). > > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. > Big NO. We use CVS, deal with it. If you want to help people who are lazy to cvs diff and send an email, write a script that that does a submission for them automatically in a format we prefer. If you want to use git, fine, you can send git diffs to the mailing list. If someone does not have enough brain to figure out how to do things our way then we probably do not want that submission either. On the other hand, I think the issue here is not the version control system or the development method we are using, but the lack of interest or need. The openbsd ports and packages are quiet good compared to others and things just work. There is always room for imrovement of course.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > In my opinion, our main issue is the lack of new blood. > > We have chronically fewer people who can give okays than ports waiting. > > One big "meta" stuff that needs doing is pointing out (especially from > new guys) what can be improved in the documentation of the porting process... > sometimes pointing people in the right direction. > > Informal poll: what thing weirded you guys out the first time you touched > OpenBSD ports coming from other platforms. > > What kind of gotcha can we get rid of, so that "new ports" will tend to > be squeaky clean, infrastructure-wise, and ready for import. > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > main differences to (say) deb, rpm, freebsd ?... Using CVS and dealing with tarballs is probably pretty ancient-feeling for many outsiders. I don't know that more documentation is really the problem. I personally tend to ignore most ports@ emails that aren't diffs I can easily view in my e-mail client because it's a hassle to save the attachment, tar -t it to see what its directory structure is, untar it in the proper place, try to build it, then provide feedback by copying parts of the Makefile to an e-mail or doing some other work to produce a diff. Maybe we can do something radical like enable GitHub pull requests to let people submit changes against the ports repo on GitHub, do review and feedback on those on GitHub, and once it's been approved by a developer, that developer can do the final legwork of committing it to CVS and closing the pull request (since we can't commit directly to the Git repo). I believe that the GitHub repo can be configured to also email ports@openbsd.org on any submissions/comments there, so the mailing list would still be in the loop on everything for anyone that doesn't want to use GitHub.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
In my opinion, our main issue is the lack of new blood. We have chronically fewer people who can give okays than ports waiting. One big "meta" stuff that needs doing is pointing out (especially from new guys) what can be improved in the documentation of the porting process... sometimes pointing people in the right direction. Informal poll: what thing weirded you guys out the first time you touched OpenBSD ports coming from other platforms. What kind of gotcha can we get rid of, so that "new ports" will tend to be squeaky clean, infrastructure-wise, and ready for import. Maybe we'd need an FAQ from people coming from elsewhere explaining the main differences to (say) deb, rpm, freebsd ?...
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Thu, Jan 20, 2022 at 11:33:41PM -0500, Kurt Mosiejczuk wrote: > Generally only folks who can commit to CVS should be asking "ok?" > > It signals to others that you are also an OpenBSD dev. One might think > that doing this may get you quicker reivew attention, except it may also > mean that you get an ok and your work never gets committed. Why? Because > we'll assume you can do so yourself. We try not to "steal" other > developer's commits. So you may get "ok" as an answer and no one will > follow up on it. > > So it's not that I'm saying "you're not part of the club, don't use our > secret handshake", it's more that by using the secret handshake you may > end up hurting yourself. :) > > --Kurt (kmos@) > So what is the best way to ask for comments and then a commit from someone? I see several situations: 1. New Port (2 OK's) 2. Revised New Port in the thread (2 OK's) 3. Update to a Port (1 OK, right?) 4. Revised Update to a Port (1 OK, right?) I've gotten tied up in working on something I would like to offer as a new port I'm working on and coding. Also figuring out how to do responsive CSS. I also have another set of ports to get in for another project. Apart from the above, I would really love some sort of template for new/updated ports that are for bigger projects. An email template stating what bigger project it is, what type of ports are for. Maybe something like? [NEW] Ports for Great Project, core depends, amd64 tested. [NEW] Ports for Great Project, optional depends, arm64 tested [NEW] Ports for Great Project, development depends, i386 tested [UPDATE] Ports for Great Project, core depends, i386 tested [NEW] Port of Great Project Also, what is a "proper" timing for pinging? In the Porter Handbook, I would really like to see some examples of harder ports to bring in. I see the same questions repeated over and over on the mailing lists. I wouldn't mind spending that time myself, with a little pointing at good, existing candidates to document. "RTFPH and then ask questions" might save a lot of the work giving advice by the porting pro's. I would love to see fvwm3 brought in, since it's the latest. I use fvwm2 right now. But projects like that are a lot of work. Which I don't know how to do. -- Thanks, Chris Bennett
FYI - On the subject of non-OpenBSD developers asking "ok?"
Generally only folks who can commit to CVS should be asking "ok?" It signals to others that you are also an OpenBSD dev. One might think that doing this may get you quicker reivew attention, except it may also mean that you get an ok and your work never gets committed. Why? Because we'll assume you can do so yourself. We try not to "steal" other developer's commits. So you may get "ok" as an answer and no one will follow up on it. So it's not that I'm saying "you're not part of the club, don't use our secret handshake", it's more that by using the secret handshake you may end up hurting yourself. :) --Kurt (kmos@)
