Re: Migrate to git?
On Sat, Oct 05, 2019 at 04:09:34PM -0400, Jim Jagielski wrote: > Various PMCs have made their default/de-facto SCM git and have seen an > increase in contributions and contributors... > > Is this something the httpd project should consider? Especially w/ the > foundation officially supporting Github, it seems like time to have a > discussion about it, especially as we start thinking about the next 25 years > of this project :) > Hi, At W3C, all the Working Group spec as well as some developer work has moved on over to github. We use github's hooks API to connect actions on github repositories with our mailing lists and other aspects of the main server. Yes, git and github may have a steeper learning curve that svn, but people now seem satisfied with the current workflow. Yes, having this kind of work hosted at github has increased its visibility and getting unexpected external contributions. For the record, part of this change of system required migrating CVS repositories from our servers at W3C to github, while preserving all the history of commits and names of commiteers, using readily available tools. There were some incompatibilities between CVS unmerged branches, though, and we had to take decisions in that case. This may not be the case for SVN. Another important reason that pushed for this migration is that CVS clients are becoming less available across platforms. I'm not sure if that's the same situation for SVN, although I see there are still recent releases of it. It helps it's hosted at ASF. For simplicity, from here one I will use "apache" to refer to the httpd server. I think that one step for migrating apache to github would require your writing down a list of things you need from a DRCS and then working on how to map them to github. One thing that I find important is that you evaluate how you're going to handle contributions, or, in git parlance, merge requests (MR). These are public visible in the repository. Having too many hanging out without closure doesn't speak well for a project. I talk of this from experience of seeing that bug reportss and proposed bug fixes are quickly fixed and integrated into apache (Thanks Yann!), however, proposal for extensions of existing modules, even when developed in consultation with the list, just go dormant and require multiple prodding today and even like that, the hit ratio is really low in my opinion. After I while this just demotivated me from continuing proposing them to this list and just stick to the ocassional bug report / patches.. See for example the latest one, dating from 2015 [1]. When this happens in github, the result may be that someone forks your project and makes a new one out of it. Another thing from the migration that I think you should consider is what you're going to do with your existing bugzilla content. Are you going to keep using it or use the github issues for that? Are you going to migrate open issues there? How about the links in reports pointing to your svn repository? Finally, as much as migrating to github can be interesting, you must also consider not being tied to github in case any future policy changes don't please you. You must be prepared to be able to migrate to another system if needed and see how much of the github environment can follow you. Can the issues follow you? How about the discussions in github? etc. What parts of github are you going to use, which ones disable (and can they be disabled?). Other alternatives for github are gitlab. You can install an instance of gitlab locally or use their repository. Upon the announcement of MS buying github, some projects migrated to gitlab. If it may help, I can put you in contact with the people in our team that can describe more in detail how W3C is using github today, the hooks, CI, how we backup it, and the advantages and limitations we have found so far. Hope this feedback helps, --josé [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58025
Re: Time for httpd 2.6.x?
Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports from trunk have maintained the 2.4.x ABI backwards compatibility. So I would propose that if we do the below, which I am fine w/ BTW, that the 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI changes. Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, untested and wonky stuff that I would be somewhat worried about releasing... So that's why I like basing 2.6.x off of 2.4.x rather than trunk. FTR: Both APR and httpd have similar versioning guidelines (semver)... I don't see the attraction or need to revisit it. > On Oct 23, 2019, at 9:02 AM, Luca Toscano wrote: > > Thanks a lot for all the answers, waiting for more people to chime in! > What I personally like (at a very high level): > > 1) create a 2.6.x branch from 2.4.x and start backporting commits from > trunk (with votes etc..), up to the point that we feel 2.6.0 GA is > ready, then follow the regular release process. Christophe's tool for > visualizing diffs between trunk and 2.4.x could be really handy and > helpful. > 2) Leave trunk as it is, and consider fixing the issues currently outstanding. > 3) Use STATUS to decide what modules/code is to be deprecated. > 4) Decide when 2.4.x should be considered EOLed in the future. > 5) Decide how/when to bump minor versions in the future, so anybody > adding/contributing code to httpd will have a very high level > expectation of when some code can be released. IIRC during the past > threads it was mentioned that a lot of people contributed with good > code still sitting in trunk due to backporting issues to 2.4.x > (breaking ABI etc..). It is not really fair and it surely drives away > contributors that aim to work on major changes to httpd. > > Luca > > > Il giorno mer 23 ott 2019 alle ore 10:40 Stefan Eissing > ha scritto: >> >> Hi All, >> >> I agree with CJ here. >> >> As I said in the past, my idea would be to: >> - trunk -> trunk-old, >> - copy 2.4.x -> trunk >> - any feature to bring from trunk-old to the new trunk needs a champion, >> e.g. someone who does the work (porting and test cases) >> >> To some, that looks like we do not honour past work from people (that was >> one of the arguments brought forward last time). But it is not only about >> honour of devs, but also about the sweat and tears of the maintainers during >> 2.6.x releases. If a feature does not find someone to merge from one branch >> to another, how could we support this feature in a release? What do the 5-6 >> people who handle 99% of all PRs think about this? >> >> As to the list of things to abandon from 2.4.x, we could handle those like >> the backport voting in STATUS. >> >> Cheers, Stefan >> >>> Am 23.10.2019 um 10:18 schrieb Christophe JAILLET >>> : >>> >>> Hi Luco, >>> >>> I've nothing against a 2.6.x branch. >>> My only fear is things in trunk that is incomplete and or not enough >>> reviewed. >>> In other words, our backport mechanism with at least 3 votes is safeguard >>> for me. >>> >>> My personal point of view is that 2.6.x should be built with backports from >>> trunk, just as done actually for 2.4.x. >>> But I know it is not the point of view of many others that consider that >>> what is in trunk is (or should be) functional, reviewed and tested. >>> Anyway, even if some things are less reviewed, alpha, beta and GA are there >>> to give others the opportunity to test and report issues, so I is maybe not >>> that bad to go this way, after all. >>> >>> >>> If we want to go on the 2.6 way, maybe we could open some discussion: >>> >>> - should we deprecate or remove some 2.4.x functionalities or modules? >>> (mod_imagemap, mod_cern_meta, maybe NetWare support which has really low >>> activity, ...) >>> >>> - should we remove things in trunk that are incomplete or lack consensus: >>> (this illustrate my fears above) >>>- mod_serf and libserf support? : serf project looks mostly inactive >>> nowadays, mod_sef have no documentation >>>- pcre2 support? (comments in commits or code say that it is >>> incomplete and that there is performance or memory management issues) >>>- things listed in 2.4/STATUS: PATCHES/ISSUES THAT ARE STALLED >>> >>> - should we increase the APR minimum version and cleanup existing code >>> accordingly? (i.e. switch from some ap_ to apr_ functions) >>> >>> - we could start to write a "new_features_2_6.html" in order to list new >>> goodies and incompatibilities and changed behavior >>> >>> >>> just my 2c. >>> >>> CJ >>> >>> Le 23/10/2019 à 08:28, Luca Toscano a écrit : Not even a comment? :) Luca Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano ha scritto: > Hi everybody, > > in trunk's STATUS there are a lot of suggestions about things to > improve/change for 2.6.x. There have been discussions during the past > couple of years about
Re: Time for httpd 2.6.x?
Disclaimer: I've been pretty much absentee for a while so take my opinions with a grain of salt. >From a PR perspective, 7 years is a heck of a long time and it would be great to remind people that httpd is in fact an actively developed project doing exciting and modern things. mod_md all by itself justifies a big splash - most of the world appear to be still completely unaware of it and while I know version numbers mean more (and sometimes less) than "yay new thing" it gives us an opportunity to make a bigger splash. Apachecon 2020 will be our 25th birthday, as has been mentioned. Having a New Shiny to talk about on such an important year would be awesome. Shosholoza, Rich On Sun, Oct 13, 2019, 20:59 Luca Toscano wrote: > Hi everybody, > > in trunk's STATUS there are a lot of suggestions about things to > improve/change for 2.6.x. There have been discussions during the past > couple of years about how/when/if to create a 2.6 release branch, but > for a lot of reasons we didn't do any progress. Would it be something > to consider for the next months? > > Luca >
